MySQL 記憶體相關引數設定
- read_buffer_size = 16M
- MyISAM 表順序掃描的快取大小，如果要經常順序掃描 MyISAM 表，可以通過增大 read_buffer_size 的值來改善效能，但是這個變數是每會話獨佔，如果設定太大，會造成記憶體浪費，甚至實體記憶體耗盡。
- 在以下場景中適用於所有的儲存引擎
- 此選項也在以下場景中用於所有儲存引擎：
* 控制 ORDER BY 行排序時的臨時檔案（不是臨時表，而是排序
的檔案）中快取索引的大小
* 控制批量插入到分割槽中的資料大小
* 控制快取巢狀查詢的結果集大小
- memory 儲存引擎中該引數的值決定 MEMORY 表的記憶體塊大小，注意是塊大小，而不是 memory 表可以使用的記憶體總大小，memory 引擎表的資料總大小限由max_heap_table_size 引數控制。
- 全域性，會話變數，預設為 128K，最大為 2G，整型值。注意：設定值必須為 4K 的倍數，否則會擷取你設定值的最接近 4K 的倍數的值作為該引數的值。取值範圍為：8200~2147479552 位元組。
- PS：為啥這個變數官方描述的是用於 MyISAM，而在某些場景也適用於所有儲存引擎呢？因為在這些場景下，mysql 內部儲存這些臨時資料仍然使用的是 MyISAM 表，在 mysql 5.7.x 的版本中，這些內部臨時表可以設定使用 InnoDB 儲存引擎，如果臨時表設定為 InnoDB 儲存引擎，則這個引數的大小就無需多關注了（除非你使用 MyISAM 引擎和 memory 引擎）。
- MyISAM 表順序掃描的快取大小，如果要經常順序掃描 MyISAM 表，可以通過增大 read_buffer_size 的值來改善效能，但是這個變數是每會話獨佔，如果設定太大，會造成記憶體浪費，甚至實體記憶體耗盡。
- read_rnd_buffer_size = 32M
- MyISAM 表排序快取的快取大小（注意，是 key-sorting 索引排序），如果需要對 MyISAM 表做排序，可以增大 read_rnd_buffer_size 改善效能，這個變數同樣的每會話獨佔，也不能設定太大。
- 該變數控制的 buffer 在從任何儲存引擎讀取資料的時候，都會用於快取讀取的資料，包括 MRR 優化特性也會使用。
- 全域性，會話變數，動態變數，預設值為 256K，最大值為 2G，整型值。取值範圍 1~2147483647 位元組（2G）。
- MyISAM 表排序快取的快取大小（注意，是 key-sorting 索引排序），如果需要對 MyISAM 表做排序，可以增大 read_rnd_buffer_size 改善效能，這個變數同樣的每會話獨佔，也不能設定太大。
- sort_buffer_size = 32M
- 用於存放排序資料的快取大小，超過這個大小就會使用檔案排序。如果通過 show global status 看到 Sort_merge_passes 的值很大，可以考慮通過適當調整 sort_buffer_size 的值來增大排序快取區（另外增加max_sort_length 引數的值時可能也需要增加 sort_buffer_size 引數的值），改善帶有 order by 和 group by 子句的 sql 效能。sort_buffer_size 是每執行緒獨佔分配（每個執行排序操作的會話才會分配），不要設定過大，最好是設定一個較小的全域性值，如果碰到較大表做排序，就對這個 session 設定較大的值。
- 該引數適通用於所有儲存引擎，最小值必須要足夠大，至少要在排序緩衝中能夠存放 15 個排序元組。
- 5.6.4 之前的版本總是在有排序操作時直接分配整個排序緩衝給會話，從 5.6.4 版本開始優化器嘗試計算排序資料的大小來分配排序緩衝的大小給會話。
- 在 linux 上，大於 256K 或者 2M 的排序緩衝大小可能顯著降低記憶體分配的效能。
- 全域性變數，會話變數，動態變數，預設值在不同版本中頻繁變化，大於 5.6.4 版本號的 64 位版本預設值為 256K，整型值。64位平臺取值範圍為：32768~18446744073709551615 位元組。
- 用於存放排序資料的快取大小，超過這個大小就會使用檔案排序。如果通過 show global status 看到 Sort_merge_passes 的值很大，可以考慮通過適當調整 sort_buffer_size 的值來增大排序快取區（另外增加max_sort_length 引數的值時可能也需要增加 sort_buffer_size 引數的值），改善帶有 order by 和 group by 子句的 sql 效能。sort_buffer_size 是每執行緒獨佔分配（每個執行排序操作的會話才會分配），不要設定過大，最好是設定一個較小的全域性值，如果碰到較大表做排序，就對這個 session 設定較大的值。
- tmp_table_size = 64M
- 記憶體臨時表超過這個大小後，就會把記憶體臨時錶轉換為磁碟臨時表，執行緒級別的引數，不要設定過大，一般全域性設定不大於 100M 就可以了，否則很容易發生記憶體溢位，但是，如果說在臨時大資料查詢的時候，可以開啟一個會話臨時設定大一點，避免產生臨時磁碟表。或者，可以使用索引查詢儘量減少返回的資料量。
- 內部用於控制記憶體臨時表大小使用，是適用於使用者建立的記憶體表和臨時表。
- 實際限制從 tmp_table_size 和 max_heap_table_size 兩個變數的的值中取較小值。 如果記憶體中臨時表超過這個限制，MySQL會自動將其轉換為磁碟上的 MyISAM 表。 如果您執行許多高階GROUP BY 查詢並且用到大量記憶體，請增加 tmp_table_size 的值（如果必要，也請增加 max_heap_table_size 的值）。
- 狀態變數 Created_tmp_disk_tables 持續增加時，需要增加tmp_table_size 的值。
- Created_tmp_disk_tables/(Created_tmp_disk_tables+Created_tmp_tables)*100% > 10%的話，就需要注意適當提高tmp_table_size 的大小，但是不能設定太大，因為它是每個session 都會分配的，可能會導致 OOM(out of memory）。
- 全域性變數，會話變數，動態變數，預設值為 16M，整型值。取值範圍為：1024~18446744073709551615 位元組。
- 記憶體臨時表超過這個大小後，就會把記憶體臨時錶轉換為磁碟臨時表，執行緒級別的引數，不要設定過大，一般全域性設定不大於 100M 就可以了，否則很容易發生記憶體溢位，但是，如果說在臨時大資料查詢的時候，可以開啟一個會話臨時設定大一點，避免產生臨時磁碟表。或者，可以使用索引查詢儘量減少返回的資料量。
- max_heap_table_size=64M
- 預設是 16M，可以根據需要加大，在定義記憶體表時，可以使用max_rows 子句指定表的最大行數來約定記憶體表的資料量。該引數是用於控制使用者建立的記憶體表的資料大小。
- 設定此變數不會影響任何現有的 MEMORY 表，除非使用如CREATE TABLE 或使用 ALTER TABLE 或 TRUNCATE TABLE 語句重新建立表、修改表結構或清空表資料。 伺服器重新啟動也會將現有 MEMORY 表的資料最大大小限制設定為全域性max_heap_table_size 值。
- 此變數也與 tmp_table_size 結合使用以限制內部記憶體表的大小。如果設定與 tmp_table_size 大小不一樣，則控制內部記憶體臨時表以較小的為準。
- 全域性變數，會話變數，動態變數，64 位版本預設值為 16M，整型值。取值範圍為：16384~1844674407370954752 位元組。
- 預設是 16M，可以根據需要加大，在定義記憶體表時，可以使用max_rows 子句指定表的最大行數來約定記憶體表的資料量。該引數是用於控制使用者建立的記憶體表的資料大小。
- join_buffer_size = 32M
- 用於存放 join 查詢中間結果的快取大小。對於無法通過索引進行聯結操作的查詢，可以通過適當增大 join_buffer_size 的值來改善聯結查詢效能（但最好是想辦法讓 join 使用到索引來提高效能）。join_buffer_size 都是每執行緒獨佔分配，不要設定過大（除非能夠使用BKA 特性，當使用 BKA 時，join_buffer_size 的值的大小決定了向儲存引擎的每個請求中包含的鍵值對的多少，緩衝區越大，聯結操作的右表即被驅動表的順序 I/O 訪問就越多，BKA 的作用就是把隨機 I/O 訪問變為順序 I/O 訪問，這可以顯著提高效能），最好是設定一個較小的全域性值，如果碰到較大表做聯結查詢，或者是比較複雜的聯結表查詢，就對這個 session 設定較大的值。
- 對於簡單查詢的索引掃描、索引範圍掃描以及因為不能使用到索引做全表掃描的 join 查詢時，無論返回的資料多大，都會分配該引數的最小值 128 位元組那麼多 join buffer 做查詢。
- 對於簡單的兩個表之間的查詢分配一個 join buffer，但是對於複雜的多表 join 查詢且不能使用索引的時候，可能會分配多個 join buffer。
- 全域性變數，會話變數，動態變數，預設值在不同版本中頻繁變化，大於 5.6.6 版本號的 64 位版本預設值為 256K，最小值為128 位元組，整型值。取值範圍為：128~18446744073709547520 位元組。
- 用於存放 join 查詢中間結果的快取大小。對於無法通過索引進行聯結操作的查詢，可以通過適當增大 join_buffer_size 的值來改善聯結查詢效能（但最好是想辦法讓 join 使用到索引來提高效能）。join_buffer_size 都是每執行緒獨佔分配，不要設定過大（除非能夠使用BKA 特性，當使用 BKA 時，join_buffer_size 的值的大小決定了向儲存引擎的每個請求中包含的鍵值對的多少，緩衝區越大，聯結操作的右表即被驅動表的順序 I/O 訪問就越多，BKA 的作用就是把隨機 I/O 訪問變為順序 I/O 訪問，這可以顯著提高效能），最好是設定一個較小的全域性值，如果碰到較大表做聯結查詢，或者是比較複雜的聯結表查詢，就對這個 session 設定較大的值。
- thread_cache_size = 64
- 為加快資料庫連線的速度，mysql 會快取一定數量的客戶端服務執行緒以備重用，通過這個引數可以控制 mysql 快取客戶端服務執行緒的數量，可以通過計算執行緒 cache 的失效率：Threads_created/Connections 狀態變數比值來衡量 thread_cache_size 引數的設定是否合理，該值越接近 1，說明執行緒 cache 的命中率越低，就應該考慮增加這個引數的值。
- 當一個客戶端訪問完成斷開連線時，如果執行緒快取中的客戶端連線執行緒沒有達到 thread_cache_size 定義的值，則這個客戶端執行緒會被 put 到快取中，當另外一個客戶端新建連線時，如果執行緒快取不為空（即有客戶端執行緒快取線上程快取中），就會從快取中取出這個客戶端連線進行重用。在大多數情況下，如果你的併發連線不高的時候，這個值對效能的影響可能就看不出來，但是當有大量併發連線時，通過增大這個值可以緩解高併發連線的壓力。
- 預設值為-1，表示自動計算（計算公式：8 + (max_connections/ 100)），全域性變數，動態變數，整型值。固定值取值範圍為：0~16384
- PS：這個變數對嵌入式伺服器（libmysqld）沒有任何影響，而在 MySQL 5.7.2 在嵌入式伺服器中移除了這個變數。
- 為加快資料庫連線的速度，mysql 會快取一定數量的客戶端服務執行緒以備重用，通過這個引數可以控制 mysql 快取客戶端服務執行緒的數量，可以通過計算執行緒 cache 的失效率：Threads_created/Connections 狀態變數比值來衡量 thread_cache_size 引數的設定是否合理，該值越接近 1，說明執行緒 cache 的命中率越低，就應該考慮增加這個引數的值。
引數：
儲存引擎/共享
日誌緩衝區，緩衝區池
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_buffer_size
伺服器/共享
查詢調整快取
執行緒高速絡快取
query_cache
table_cahce
table_definition_cache
連線/會話
排序緩衝區，讀取緩衝區，臨時表
binlog_cache_size
read_buffer_size
read_rnd_buffer_size
join_buffer_size
sort_buffer_size
tmp_table_size
thread_cache_size
bulk_insert_buffer_size
net_buffer_length
thread_stack
下面轉載自：http://www.bitscn.com/pdb/mysql/201405/227583.html
*.執行緒獨享記憶體
*.全域性共享記憶體
全域性共享記憶體類似ORACLE的系統全域性區SGA，執行緒獨享記憶體類似ORACLE的程序全域性區PGA
一、執行緒獨享記憶體
在MySQL中，執行緒獨享記憶體主要用於各客戶端連線執行緒儲存各種操作的獨享資料，如執行緒棧資訊，分組排序操作，資料讀寫緩衝，結果集暫存等等，而且大多數可以通過相關引數來控制記憶體的使用量。
* 執行緒棧資訊使用記憶體(thread_stack)：
主要用來存放每一個執行緒自身的標識資訊，如執行緒id，執行緒執行時基本資訊等等，我們可以通過 thread_stack 引數來設定為每一個執行緒棧分配多大的記憶體。
Global,No Dynamic,Default 192K(32bit), 256K(32bit),
推薦配置：預設
* 排序使用記憶體(sort_buffer_size)：
MySQL 用此記憶體區域進行排序操作(filesort)，完成客戶端的排序請求。當我們設定的排序區快取大小無法滿足排序實際所需記憶體的時候，MySQL會將資料寫入磁碟檔案來完成排序。由於磁碟和記憶體的讀寫效能完全不在一個數量級，
所以sort_buffer_size引數對排序操作的效能影響絕對不可小視。排序操作的實現原理請參考：MySQL Order By的實現分析。
什麼時候會用到？
對結果集排序時
使用確認：
可以通過查詢計劃中的Extra列的值為Using file-sort來證實使用了和這個緩衝區。
>explain select * from user1;
Global Session,Dynamic,Default 2M(32bit), 2M(32bit),
推薦配置：8M（記憶體足夠的情況下），預設（記憶體緊張的情況）
優化建議：一種說法是增大可以提高order by,group by效能，防止資料寫入磁碟佔用IO資源，還有一種說法是不推薦增加這個緩衝區的大小，理由是當值太大時可能會降低查詢的執行速度。目前我沒有實驗證實。
* Join操作使用記憶體(join_buffer_size)：
應用程式經常會出現一些兩表（或多表）Join的操作需求，MySQL在完成某些Join需求的時候（all/index join），為了減少參與Join的“被驅動表”的讀取次數以提高效能，需要使用到Join Buffer來協助完成Join操作
（具體Join實現演算法請參考：MySQL中的 Join 基本實現原理）。當Join Buffer太小，MySQL 不會將該Buffer存入磁碟檔案，而是先將Join Buffer中的結果集與需要Join的表進行Join操作，然後清空Join Buffer中的資料，
繼續將剩餘的結果集寫入此Buffer中，如此往復。這勢必會造成被驅動表需要被多次讀取，成倍增加IO訪問，降低效率。
什麼時候會用到？
當查詢必須連線兩個表（或多個）的資料集並且不能使用索引時，這個緩衝區會被用到。這個緩衝區專門為每個執行緒的無索引連結操作準備的。
使用確認：
可以通過查詢計劃中的Extra列的值為Using join bufer來證實使用了和這個緩衝區。
>explain select * from user1; +------+-------------+-------+-------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+-------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | user1 | index | NULL | name | 78 | NULL | 3 | Using index | +------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
Global Session,Dynamic,Default 128K 各版本平臺最大值不一樣
推薦配置：8M（記憶體足夠的情況下），預設（記憶體緊張的情況）
優化建議：有一種說法是增加這個緩衝區的大小不會加快全連線操作的速度。目前我沒有實驗證實。
* 順序讀取資料緩衝區使用記憶體(read_buffer_size)：
這部分記憶體主要用於當需要順序讀取資料的時候，如無法使用索引的情況下的全表掃描，全索引掃描等。在這種時候，MySQL按照資料的儲存順序依次讀取資料塊，每次讀取的資料快首先會暫存在read_buffer_size中，
當buffer空間被寫滿或者全部資料讀取結束後，再將buffer中的資料返回給上層呼叫者，以提高效率。
Global Session,Dynamic,Default 128K
推薦配置：4M/8M
* 隨機讀取資料緩衝區使用記憶體(read_rnd_buffer_size)：
和順序讀取相反，當MySQL進行非順序讀取（隨機讀取）資料塊的時候，會利用這個緩衝區暫存讀取的資料。如根據索引資訊讀取表資料，根據排序後的結果集與表進行Join等等。
總的來說，就是當資料塊的讀取需要滿足一定的順序的情況下，MySQL就需要產生隨機讀取，進而使用到read_rnd_buffer_size 引數所設定的記憶體緩衝區。
Global Session,Dynamic,Default 256K
推薦配置：8M
* 連線資訊及返回客戶端前結果集暫存使用記憶體(net_buffer_lenth)：
這部分用來存放客戶端連線執行緒的連線資訊和返回客戶端的結果集。當MySQL開始產生可以返回的結果集，會在通過網路返回給客戶端請求執行緒之前，會先暫存在通過net_buffer_lenth所設定的緩衝區中，
等滿足一定大小的時候才開始向客戶端傳送，以提高網路傳輸效率。不過net_buffer_lenth引數所設定的僅僅只是該快取區的初始化大小，MySQL會根據實際需要自行申請更多的記憶體以滿足需求，
但最大不會超過 max_allowed_packet 引數大小。
Global Session,Dynamic,Default 16K
推薦配置：預設 16K
* 批量插入暫存使用記憶體(bulk_insert_buffer_size)：
當我們使用如 insert … values(…),(…),(…)… 的方式進行批量插入的時候，MySQL會先將提交的資料放如一個快取空間中，當該快取空間被寫滿或者提交完所有資料之後，MySQL才會一次性將該快取空間中的資料寫入資料庫並清空快取。
此外，當我們進行 LOAD DATA INFILE操作來將文字檔案中的資料Load進資料庫的時候，同樣會使用到此緩衝區。
Global Session,Dynamic,Default 8M
推薦配置：預設 8M
* 臨時表使用記憶體(tmp_table_size)：
當我們進行一些特殊操作如需要使用臨時表才能完成的Order By,Group By 等等，MySQL可能需要使用到臨時表。當我們的臨時表較小（小於tmp_table_size 引數所設定的大小）的時候，MySQL會將臨時表建立成記憶體臨時表，
只有當tmp_table_size所設定的大小無法裝下整個臨時表的時候，MySQL才會將該表建立成MyISAM儲存引擎的表存放在磁碟上。不過，當另一個系統引數 max_heap_table_size 的大小還小於 tmp_table_size 的時候，
MySQL將使用 max_heap_table_size 引數所設定大小作為最大的記憶體臨時表大小，而忽略tmp_table_size 所設定的值。而且 tmp_table_size 引數從 MySQL 5.1.2 才開始有，之前一直使用 max_heap_table_size。
誰小誰生效.另外還有一個引數max_tmp_tables,沒有使用
tmp_table_size
Global Session,Dynamic,Default 16M
推薦配置：64M
max_heap_table_size
Global Session,Dynamic,Default 8M
This variable sets the maximum size to which user-created MEMORY tables are permitted to grow
這個變數定義了MEMORY儲存引擎表的最大容量。
This variable is also used in conjunction with tmp_table_size to limit the size of internal in-memory tables. See
這個變數也與tmp_table_size一起使用限制內部記憶體表的大小。請見
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
推薦配置：64M
主要根據業務以及伺服器記憶體來調整，如果有需要到則可以調整到。GB居然使用2G的配置，汗
目前沒有一個簡便的方式來確定內部臨時表的總容量。可以通過MySQL狀態變數created_tmp_tables和created_tmp_disk_tables來確定建立了臨時表和基於磁碟的臨時表
mysql> show global status like 'create%tables'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | | Created_tmp_tables | 0 | +-------------------------+-------+
5.5中，可以使用PERFORMANCE—SCHEMA來幫助統計基於磁碟的臨時表的總大小
補充說明：上面所列舉的MySQL執行緒獨享記憶體僅僅只是所有執行緒獨享記憶體中的部分，並不是全部，只是這些可能對MySQL的效能產生較大的影響，且可以通過系統引數進行調節。
由於以上記憶體都是執行緒獨享，極端情況下的記憶體總體使用量將是所有連線執行緒的總倍數。所以在設定過程中一定要謹慎，切不可為了提升效能就盲目的增大各引數值，
避免因為記憶體不夠而產生Out Of Memory異常或者是嚴重的Swap交換反而降低整體效能。
二、全域性共享記憶體
全域性共享內則主要是MySQL Instance以及底層儲存引擎用來暫存各種全域性運算及可共享的暫存資訊，如
儲存查詢快取的 Query Cache，
快取連線執行緒的 Thread Cache，
快取表文件控制代碼資訊的 Table Cache，
快取二進位制日誌的 BinLog Buffer，
快取MyISAM儲存引擎索引鍵的 Key Buffer
儲存InnoDB資料和索引的 InnoDB Buffer Pool
等等。下面針對 MySQL 主要的共享記憶體進行一個簡單的分析。
* MyISAM索引快取 Key Buffer（key_buffer_size）：
MyISAM 索引快取將MyISAM表的索引資訊（.MYI檔案）快取在記憶體中，以提高其訪問效能。這個快取可以說是影響MyISAM儲存引擎效能的最重要因素之一了，通過 key_buffere_size 設定可以使用的最大記憶體空間。
注意：即使執行一個全部採用innodb的模式，仍需要定義一個索引碼緩衝區，因為MYSQL元資訊與MyISAM定義相同。
Global ,Dynamic,Default 8M
推薦配置：預設 8M
如何確認key_buffer_size不夠用？
使用show full proceslist的State列中，值Repairing the keycache是一個明顯的指標，它指出當前索引碼緩衝區大小不足以執行當前執行的SQL語句。這將導致額外的磁碟I/O開銷。
* 查詢快取 Query Cache （query_cache_size）：
http://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/query-cache-status-and-maintenance.html
查詢快取是MySQL比較獨特的一個快取區域，用來快取特定Query的結果集（Result Set）資訊，且共享給所有客戶端。通過對Query語句進行特定的Hash計算之後與結果集對應存放在Query Cache中，以提高完全相同的Query語句的相應速度。
當我們開啟MySQL的Query Cache之後，MySQL接收到每一個SELECT型別的Query之後都會首先通過固定的Hash演算法得到該Query的Hash值，然後到Query Cache中查詢是否有對應的Query Cache。如果有，則直接將Cache的結果集返回給客戶端。
如果沒有，再進行後續操作，得到對應的結果集之後將該結果集快取到Query Cache中，再返回給客戶端。當任何一個表的資料發生任何變化之後，與該表相關的所有Query Cache全部會失效，所以Query Cache對變更比較頻繁的表並不是非常適用，
但對那些變更較少的表是非常合適的，可以極大程度的提高查詢效率，如那些靜態資源表，配置表等等。為了儘可能高效的利用Query Cache，MySQL針對Query Cache設計了多個query_cache_type值
和兩個Query Hint：SQL_CACHE和SQL_NO_CACHE。當query_cache_type設定為0（或者 OFF）的時候不使用Query Cache，當設定為1（或者 ON）的時候，當且僅當Query中使用了SQL_NO_CACHE 的時候MySQL會忽略Query Cache，
當query_cache_type設定為2（或者DEMAND）的時候，當且僅當Query中使用了SQL_CACHE提示之後，MySQL才會針對該Query使用Query Cache。可以通過query_cache_size來設定可以使用的最大記憶體空間。
Global Dynamic,Default 0
推薦配置：16M
如何確定系統query cache的情況？
show global status like 'Qcache%';或者
select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'Qcache%';
公式：
（Qcache_hits/Qcache_hits+Com_select+1)*100來確定查詢快取的有效性
mysql> show variables like 'query_cache_size'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 16777216 | +------------------+----------+ 1 row in set (0.00 sec) mysql> show global status like 'Qcache%'; +-------------------------+------------+ | Variable_name | Value | +-------------------------+------------+ | Qcache_free_blocks | 535 | | Qcache_free_memory | 4885448 | | Qcache_hits | 1858574835 | | Qcache_inserts | 1619931831 | | Qcache_lowmem_prunes | 802889469 | | Qcache_not_cached | 825000679 | | Qcache_queries_in_cache | 4411 | | Qcache_total_blocks | 9554 | +-------------------------+------------+ 8 rows in set (0.00 sec) mysql> show global status like 'Com_select'; +---------------+------------+ | Variable_name | Value | +---------------+------------+ | Com_select | 2445037535 | +---------------+------------+ 1 row in set (0.00 sec)
* 連線執行緒快取 Thread Cache（thread_cache_size）：
連線執行緒是MySQL為了提高建立連線執行緒的效率，將部分空閒的連線執行緒保持在一個快取區以備新進連線請求的時候使用，這尤其對那些使用短連線的應用程式來說可以極大的提高建立連線的效率。
當我們通過thread_cache_size設定了連線執行緒快取池可以快取的連線執行緒的大小之後，可以通過(Connections - Threads_created) / Connections * 100% 計算出連線執行緒快取的命中率。
注意，這裡設定的是可以快取的連線執行緒的數目，而不是記憶體空間的大小。
Global,Dynamic,Default 0
推薦配置：8個
如何確定系統Thread Cache的情況？
mysql> show global status like 'Threads_created'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | Threads_created | 506 | +-----------------+-------+ 1 row in set (0.00 sec) mysql> show global status like 'connections'; +---------------+----------+ | Variable_name | Value | +---------------+----------+ | Connections | 16513711 | +---------------+----------+ 1 row in set (0.00 sec)
16513711-506/16513711 * 100% =99.9938% 很高的命中率啊 這臺之只讀的slave
* 表快取 Table Cache（table_open_cache）：
表快取區主要用來快取表文件的檔案控制代碼資訊，在 MySQL5.1.3之前的版本通過table_cache引數設定，但從MySQL5.1.3開始改為table_open_cache來設定其大小。當我們的客戶端程式提交Query給MySQL的時候，
MySQL需要對Query所涉及到的每一個表都取得一個表文件控制代碼資訊，如果沒有Table Cache，那麼MySQL就不得不頻繁的進行開啟關閉檔案操作，無疑會對系統性能產生一定的影響，Table Cache 正是為了解決這一問題而產生的。
在有了Table Cache之後，MySQL每次需要獲取某個表文件的控制代碼資訊的時候，首先會到Table Cache中查詢是否存在空閒狀態的表文件控制代碼。如果有，則取出直接使用，沒有的話就只能進行開啟檔案操作獲得檔案控制代碼資訊。
在使用完之後，MySQL會將該檔案控制代碼資訊再放回Table Cache 池中，以供其他執行緒使用。注意，這裡設定的是可以快取的表文件控制代碼資訊的數目，而不是記憶體空間的大小。
Global,Dynamic,Default 400
推薦配置：根據記憶體配置4G 2048 大於最大Opened_tables
如何確定系統table_open_cache的情況？
mysql> show variables like 'table_open_cache'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | table_open_cache | 512 | +------------------+-------+ 1 row in set (0.00 sec) mysql> show global status like 'open%_tables'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_tables | 512 | | Opened_tables | 6841 | +---------------+-------+ 2 rows in set (0.00 sec)
調優參考：
http://blog.zfcms.com/article/282
http://www.kuqin.com/database/20120815/328904.html
兩個引數的值。其中Open_tables是當前正在開啟表的數量，Opened_tables是所有已經開啟表的數量。
如果Open_tables的值已經接近table_cache的值，且Opened_tables還在不斷變大，則說明mysql正在將快取的表釋放以容納新的表，此時可能需要加大table_cache的值。對於大多數情況，比較適合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
如果對此引數的把握不是很準，VPS管理百科給出一個很保守的設定建議：把MySQL資料庫放在生產環境中試執行一段時間，然後把引數的值調整得比Opened_tables的數值大一些，並且保證在比較高負載的極端條件下依然比Opened_tables略大。
在mysql預設安裝情況下，table_cache的值在2G記憶體以下的機器中的值預設時256到 512，如果機器有4G記憶體,則預設這個值是2048，
* 表定義資訊快取 Table definition Cache （table_definition_cache）：
表定義資訊快取是從 MySQL5.1.3 版本才開始引入的一個新的快取區，用來存放表定義資訊。當我們的 MySQL 中使用了較多的表的時候，此快取無疑會提高對錶定義資訊的訪問效率。
MySQL 提供了 table_definition_cache 引數給我們設定可以快取的表的數量。注意，這裡設定的是可以快取的表定義資訊的數目，而不是記憶體空間的大小。
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
Global, Dynamic, Default 400
推薦配置：根據記憶體配置4G 2048 和Table Cache一樣即可
* 二進位制日誌緩衝區Binlog Cache( binlog_cache_size）：
二進位制日誌緩衝區主要用來快取由於各種資料變更操做所產生的 Binary Log 資訊。為了提高系統的效能，MySQL 並不是每次都是將二進位制日誌直接寫入 Log File，而是先將資訊寫入 Binlog Buffer 中，
當滿足某些特定的條件（如 sync_binlog引數設定）之後再一次寫入 Log File 中。我們可以通過 binlog_cache_size 來設定其可以使用的記憶體大小，同時通過 max_binlog_cache_size 限制其最大大小
（當單個事務過大的時候 MySQL 會申請更多的記憶體）。當所需記憶體大於 max_binlog_cache_size 引數設定的時候，MySQL 會報錯：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。
Global,Dynamic,Default 32K
推薦配置：2M
* InnoDB 日誌緩衝區 InnoDB Log Buffer （innodb_log_buffer_size）：
這是 InnoDB 儲存引擎的事務日誌所使用的緩衝區。類似於 Binlog Buffer，InnoDB 在寫事務日誌的時候，為了提高效能，也是先將資訊寫入 Innofb Log Buffer 中，當滿足 innodb_flush_log_trx_commit 引數所設定的相應條件（或者日誌緩衝區寫滿）之後，才會將日誌寫到檔案（或者同步到磁碟）中。可以通過 innodb_log_buffer_size 引數設定其可以使用的最大記憶體空間。
注：innodb_flush_log_trx_commit 引數對 InnoDB Log 的寫入效能有非常關鍵的影響。該引數可以設定為0，1，2，解釋如下：
0：log buffer中的資料將以每秒一次的頻率寫入到log file中，且同時會進行檔案系統到磁碟的同步操作，但是每個事務的commit並不會觸發任何log buffer 到log file的重新整理或者檔案系統到磁碟的重新整理操作；
1：在每次事務提交的時候將log buffer 中的資料都會寫入到log file，同時也會觸發檔案系統到磁碟的同步；
2：事務提交會觸發log buffer 到log file的重新整理，但並不會觸發磁碟檔案系統到磁碟的同步。此外，每秒會有一次檔案系統到磁碟同步操作。
此外，MySQL文件中還提到，這幾種設定中的每秒同步一次的機制，可能並不會完全確保非常準確的每秒就一定會發生同步，還取決於程序排程的問題。實際上，InnoDB 能否真正滿足此引數所設定值代表的意義正常 Recovery 還是受到了不同 OS 下檔案系統以及磁碟本身的限制，可能有些時候在並沒有真正完成磁碟同步的情況下也會告訴 mysqld 已經完成了磁碟同步。
Global,Dynamic,Default 8M
推薦配置：8M 預設
* InnoDB 資料和索引快取 InnoDB Buffer Pool（innodb_buffer_pool_size）：
InnoDB Buffer Pool 對 InnoDB 儲存引擎的作用類似於 Key Buffer Cache 對 MyISAM 儲存引擎的影響，主要的不同在於 InnoDB Buffer Pool 不僅僅快取索引資料，還會快取表的資料，
而且完全按照資料檔案中的資料快結構資訊來快取，這一點和 Oracle SGA 中的 database buffer cache 非常類似。所以，InnoDB Buffer Pool 對 InnoDB 儲存引擎的效能影響之大就可想而知了。
可以通過 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算得到 InnoDB Buffer Pool 的命中率。
global級別，不可動態變更 Default 128M
設定InnoDB資料和索引記憶體快取空間大小
配置方式：配置檔案中配置
選擇引數：50 - 80 % RAM
mysql> show variables like '%innodb_buffer%'; +------------------------------+-----------+ | Variable_name | Value | +------------------------------+-----------+ | innodb_buffer_pool_instances | 1 | | innodb_buffer_pool_size | 268435456 | +------------------------------+-----------+ 2 rows in set (0.00 sec)
通過show global status和show engine innodb status/G的BUFFER POOL AND MEMORY
mysql> show global status like '%innodb_buffer%'; +---------------------------------------+--------------+ | Variable_name | Value | +---------------------------------------+--------------+ | Innodb_buffer_pool_pages_data | 15684 | | Innodb_buffer_pool_bytes_data | 256966656 | | Innodb_buffer_pool_pages_dirty | 210 | | Innodb_buffer_pool_bytes_dirty | 3440640 | | Innodb_buffer_pool_pages_flushed | 372378403 | | Innodb_buffer_pool_pages_free | 1 | | Innodb_buffer_pool_pages_misc | 698 | | Innodb_buffer_pool_pages_total | 16383 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 691803 | | Innodb_buffer_pool_read_ahead_evicted | 41350 | | Innodb_buffer_pool_read_requests | 170965099291 | | Innodb_buffer_pool_reads | 5392513 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 5825388207 | +---------------------------------------+--------------+ 15 rows in set (0.01 sec) mysql> show engine innodb status/G BUFFER POOL AND MEMORY ---------------------- Total memory allocated 274726912; in additional pool allocated 0 Dictionary memory allocated 4055091 Buffer pool size 16383 Free buffers 1 Database pages 15673 Old database pages 5765 Modified db pages 521 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 27497746, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 6346456, created 1902566, written 372381712 0.00 reads/s, 0.37 creates/s, 27.75 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 15673, unzip_LRU len: 0 I/O sum[1107]:cur[0], unzip sum[0]:cur[0]
命中率 Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
170965099291-5392513/170965099291 × 100% = 99.99%
* InnoDB 字典資訊快取 InnoDB Additional Memory Pool（innodb_additional_mem_pool_size）:
InnoDB 字典資訊快取主要用來存放 InnoDB 儲存引擎的字典資訊以及一些 internal 的共享資料結構資訊。所以其大小也與系統中所使用的 InnoDB 儲存引擎表的數量有較大關係。不過，如果我們通過 innodb_additional_mem_pool_size 引數所設定的記憶體大小不夠，InnoDB 會自動申請更多的記憶體，並在 MySQL 的 Error Log 中記錄警告資訊。
global級別，不可動態變更 Default 8M
設定InnoDB存放資料庫字典資訊的Buffer大小
推薦配置：50M
三、檢視統計
1.檢視各引數記憶體配置方式
#全域性共享記憶體 9個變數
show variables like 'innodb_buffer_pool_size'; /* InnoDB 資料和索引快取（InnoDB Buffer Pool） */
show variables like 'innodb_additional_mem_pool_size'; /* InnoDB 字典資訊快取（InnoDB Additional Memory Pool）*/
show variables like 'innodb_log_buffer_size'; /* InnoDB 日誌緩衝區（InnoDB Log Buffer） */
show variables like 'binlog_cache_size'; /* 二進位制日誌緩衝區（Binlog Buffer）*/
show variables like 'thread_cache_size'; /* 連線執行緒快取（Thread Cache）*/
show variables like 'query_cache_size'; /* 查詢快取（Query Cache）*/
show variables like 'table_open_cache'; /* 表快取（Table Cache） */
show variables like 'table_definition_cache'; /* 表定義資訊快取（Table definition Cache） */
show variables like 'key_buffer_size'; /* MyISAM索引快取（Key Buffer） */
#最大執行緒數
show variables like 'max_connections';
#執行緒獨享記憶體 6個變數
show variables like 'thread_stack'; /* 線執行緒棧資訊使用記憶體(thread_stack) */
show variables like 'sort_buffer_size'; /* 排序使用記憶體(sort_buffer_size) */
show variables like 'join_buffer_size'; /* Join操作使用記憶體(join_buffer_size) */
show variables like 'read_buffer_size'; /* 順序讀取資料緩衝區使用記憶體(read_buffer_size) */
show variables like 'read_rnd_buffer_size'; /* 隨機讀取資料緩衝區使用記憶體(read_rnd_buffer_size) */
show variables like 'tmp_table_size'; /* 臨時表使用記憶體(tmp_table_size) ，我實際計算把tmp_table_size放入全域性共享內*/
也可以通過系統變數的方式直接獲取
select @@key_buffer_size;
select @@max_connections
2.mysql記憶體計算公式
mysql使用的記憶體 = 全域性共享記憶體+最大執行緒數×執行緒獨享記憶體
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size +max_connections*（ thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size） SET @kilo_bytes=1024; SET @mega_bytes=@kilo_bytes*1024; SET @giga_bytes=@mega_bytes*1024; SELECT (@@innodb_buffer_pool_size+@@innodb_additional_mem_pool_size+@@innodb_log_buffer_size+@@binlog_cache_size+@@thread_cache_size+@@query_cache_size+@@table_open_cache+@@table_definition_cache+@@key_buffer_size+@@max_connections*(@@thread_stack+@@sort_buffer_size+@@join_buffer_size+@@read_buffer_size+@@read_rnd_buffer_size+@@tmp_table_size))/@giga_bytes AS MAX_MEMORY_GB;
這個理論最大的記憶體使用量，在5.5版本中tmp_table_size預設是16M，按預設u自大連線數151計算，光執行緒獨享的臨時表佔據的空間都是2416M，我實際計算把tmp_table_size放入全域性共享內
我的計算公式
mysql使用的記憶體 = 全域性共享記憶體+最大執行緒數×執行緒獨享記憶體
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size +max_connections*（ thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size）