MySQL快取問題調整
阿新 • • 發佈：2018-12-15
優化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怎麼這麼慢了。所以在資料庫寫入量或是更新量也比較大的系統，該引數不適合分配過大。而且在高併發，寫入量大的系統，建議把該功能禁掉。
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怎麼這麼慢了。所以在資料庫寫入量或是更新量也比較大的系統，該引數不適合分配過大。而且在高併發，寫入量大的系統，建議把該功能禁掉。