優化MYSQL配置文件MY.INI

table_cache=1024
物理內存越大,設置就越大.默認爲2402,調到512-1024最佳。因爲每一個客戶端鏈接都會至少訪問一個表，所以此參數的值與max_connections有關。當某一鏈接訪問一個表時，MySQL會檢查當前已緩存表的數量。若是該表已經在緩存中打開，則會直接訪問緩存中的表已加快查詢速度；若是該表未被緩存，則會將當前的表添加進緩存並進行查詢。在執行緩存操做以前，table_cache用於限制緩存表的最大數目：若是當前已經緩存的表未達到table_cache，則會將新表添加進來；若已經達到此值，MySQL將根據緩存表的最後查詢時間、查詢率等規則釋放以前的緩存。

innodb_additional_mem_pool_size=4M
默認爲2M

innodb_thread_concurrency=8
你的服務器CPU有幾個就設置爲幾,建議用默認通常爲8

key_buffer_size=256M
默認爲218,調到128最佳/用於緩存MyISAM表的索引塊。決定數據庫索引處理的速度（尤爲是索引讀）,批定用於索引的緩衝區大小，增長它能夠獲得更好的索引處理性能，對於內存在4GB左右的服務器來講，該參數可設置爲256MB或384MB。

tmp_table_size=64M
默認爲16M,調到64-256最掛

read_buffer_size=4M
默認爲64K讀查詢操做所能使用的緩衝區大小。和sort_buffer_size同樣，該參數對應的分配內存也是每鏈接獨享。 對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。若是對錶的順序掃描請求很是頻繁，而且你認爲頻繁掃描進行得太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能。和sort_buffer_size同樣，該參數對應的分配內存也是每一個鏈接獨享。

read_rnd_buffer_size=16M
默認爲256K, MySql的隨機讀（查詢操做）緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，可適當調高該值。但MySql會爲每一個客戶鏈接發放該緩衝空間，因此應儘可能適當設置該值，以免內存開銷過大。

sort_buffer_size=32M
默認爲256KSort_Buffer_Size 並非越大越好，因爲是connection級的參數，過大的設置+高併發可能會耗盡系統內存資源。例如：500個鏈接將會消耗 500*sort_buffer_size(8M)=4G內存,Sort_Buffer_Size 超過2KB的時候，就會使用mmap() 而不是 malloc() 來進行內存分配，致使效率下降。

join_buffer_size = 8M
聯合查詢操做所能使用的緩衝區大小，和sort_buffer_size同樣，該參數對應的分配內存也是每鏈接獨享。

innodb_buffer_pool_size=105M
InnoDB使用緩衝池來緩存索引和行數據。該值設置的越大，則磁盤IO越少。通常將該值設爲物理內存的80%。這對Innodb表來講很是重要。Innodb相比MyISAM表對緩衝更爲敏感。MyISAM能夠在默認的 key_buffer_size 設置下運行的能夠，然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。因爲Innodb把數據和索引都緩存起來，無需留給操做系統太多的內存，所以若是隻須要用Innodb的話則能夠設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 若是你的數據量不大，而且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了

myisam_max_sort_file_size=100G
mysql重建索引時容許使用的臨時文件最大大小,MyISAM表發生變化時從新排序所需的緩衝

query_cache_size=64M
查詢緩存大小，用於緩存SELECT查詢結果。若是有許多返回相同查詢結果的SELECT查詢，而且不多改變表，能夠設置query_cache_size大於0，能夠極大改善查詢效率。而若是表數據頻繁變化，就不要使用這個，會拔苗助長.對於使用MySQL的用戶，對於這個變量你們必定不會陌生。前幾年的MyISAM引擎優化中，這個參數也是一個重要的優化參數。但隨着發展，這個參數也爆露出來一些問題。機器的內存愈來愈大，人們也都習慣性的把之前有用的參數分配的值愈來愈大。這個參數加大後也引起了一系列問題。咱們首先分析一下 query_cache_size的工做原理：一個SELECT查詢在DB中工做後，DB會把該語句緩存下來，當一樣的一個SQL再次來到DB裏調用時，DB在該表沒發生變化的狀況下把結果從緩存中返回給Client。這裏有一個關建點，就是DB在利用Query_cache工做時，要求該語句涉及的表在這段時間內沒有發生變動。那若是該表在發生變動時，Query_cache裏的數據又怎麼處理呢？首先要把Query_cache和該表相關的語句所有置爲失效，而後在寫入更新。那麼若是Query_cache很是大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是Insert就會很慢，這樣看到的就是Update或是Insert怎麼這麼慢了。因此在數據庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。並且在高併發，寫入量大的系統，建議把該功能禁掉。

query_cache_limit = 4M 

指定單個查詢可以使用的緩衝區大小，缺省爲1M