在平時被問及最多的問題就是關於 mysql 資料庫效能優化方面的問題，所以最近打算寫乙個mysql資料庫效能優化方面的系列文章，希望對初中級 mysql dba 以及其他對 mysql 效能優化感興趣的朋友們有所幫助。
這是mysql資料庫效能優化專題系列的第一篇文章：mysql 資料庫效能優化之快取引數優化
資料庫屬於 io 密集型的應用程式，其主要職責就是資料的管理及儲存工作。而我們知道，從記憶體中讀取乙個資料庫的時間是微秒級別，而從一塊普通硬碟上讀取乙個io是在毫秒級別，二者相差3個數量級。所以，要優化資料庫，首先第一步需要優化的就是 io，盡可能將磁碟io轉化為記憶體io。本文先從 mysql 資料庫io相關引數（快取引數）的角度來看看可以通過哪些引數進行io優化：
query cache 作用於整個 mysql instance，主要用來快取 mysql 中的 resultset，也就是一條sql語句執行的結果集，所以僅僅只能針對select語句。當我們開啟了 query cache 功能，mysql在接受到一條select語句的請求後，如果該語句滿足query cache的要求（未顯式說明不允許使用query cache，或者已經顯式申明需要使用query cache），mysql 會直接根據預先設定好的hash演算法將接受到的select語句以字串方式進行hash，然後到query cache 中直接查詢是否已經快取。也就是說，如果已經在快取中，該select請求就會直接將資料返回，從而省略了後面所有的步驟（如 sql語句的解析，優化器優化以及向儲存引擎請求資料等），極大的提高效能。
當然，query cache 也有乙個致命的缺陷，那就是當某個表的資料有任何任何變化，都會導致所有引用了該錶的select語句在query cache 中的快取資料失效。所以，當我們的資料變化非常頻繁的情況下，使用query cache 可能會得不償失。
query cache的使用需要多個引數配合，其中最為關鍵的是 query_cache_size 和 query_cache_type ，前者設定用於快取 resultset 的記憶體大小，後者設定在何場景下使用 query cache。在以往的經驗來看，如果不是用來快取基本不變的資料的mysql資料庫，query_cache_size 一般 256mb 是乙個比較合適的大小。當然，這可以通過計算query cache的命中率（qcache_hits/(qcache_hits+qcache_inserts)*100)）來進行調整。query_cache_type可以設定為0(off)，1(on)或者2(demond)，分別表示完全不使用query cache，除顯式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有顯示要求才使用query cache（使用sql_cache）。
binlog_cache_size （global）binlog cache 用於在開啟了二進位制日誌（binlog）記錄功能的環境，是 mysql 用來提高binlog的記錄效率而設計的乙個用於短時間內臨時快取binlog資料的記憶體區域。
一般來說，如果我們的資料庫中沒有什麼大事務，寫入也不是特別頻繁，2mb～4mb是乙個合適的選擇。但是如果我們的資料庫大事務較多，寫入量比較大，可與適當調高binlog_cache_size。同時，我們可以通過binlog_cache_use 以及 binlog_cache_disk_use來分析設定的binlog_cache_size是否足夠，是否有大量的binlog_cache由於記憶體大小不夠而使用臨時檔案（binlog_cache_disk_use）來快取了。
key_buffer_size （global）key buffer 可能是大家最為熟悉的乙個 mysql 快取引數了，尤其是在 mysql 沒有更換預設儲存引擎的時候，很多朋友可能會發現，預設的 mysql 配置檔案中設定最大的乙個記憶體引數就是這個引數了。key_buffer_size 引數用來設定用於快取 myisam儲存引擎中索引檔案的記憶體區域大小。如果我們有足夠的記憶體，這個快取區域最好是能夠存放下我們所有的 myisam 引擎表的所有索引，以盡可能提高效能。
此外，當我們在使用myisam 儲存的時候有乙個及其重要的點需要注意，由於 myisam 引擎的特性限制了他僅僅只會快取索引塊到記憶體中，而不會快取表資料庫塊。所以，我們的 sql 一定要盡可能讓過濾條件都在索引中，以便讓快取幫助我們提高查詢效率。
bulk_insert_buffer_size （thread）和key_buffer_size一樣，這個引數同樣也僅作用於使用 myisam儲存引擎，用來快取批量插入資料的時候臨時快取寫入資料。當我們使用如下幾種資料寫入語句的時候，會使用這個記憶體區域來快取批量結構的資料以幫助批量寫入資料檔案：
insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表)
innodb_buffer_pool_size（global）當我們使用innodb儲存引擎的時候，innodb_buffer_pool_size 引數可能是影響我們效能的最為關鍵的乙個引數了，他用來設定用於快取 innodb 索引及資料塊的記憶體區域大小，類似於 myisam 儲存引擎的 key_buffer_size 引數，當然，可能更像是 oracle 的 db_cache_size。簡單來說，當我們操作乙個 innodb 表的時候，返回的所有資料或者去資料過程中用到的任何乙個索引塊，都會在這個記憶體區域中走一遭。
和key_buffer_size 對於 myisam 引擎一樣，innodb_buffer_pool_size 設定了 innodb 儲存引擎需求最大的一塊記憶體區域的大小，直接關係到 innodb儲存引擎的效能，所以如果我們有足夠的記憶體，盡可將該引數設定到足夠打，將盡可能多的 innodb 的索引及資料都放入到該快取區域中，直至全部。
我們可以通過 (innodb_buffer_pool_read_requests – innodb_buffer_pool_reads) / innodb_buffer_pool_read_requests * 100% 計算快取命中率，並根據命中率來調整 innodb_buffer_pool_size 引數大小進行優化。
innodb_additional_mem_pool_size（global）這個引數我們平時調整的可能不是太多，很多人都使用了預設值，可能很多人都不是太熟悉這個引數的作用。innodb_additional_mem_pool_size 設定了innodb儲存引擎用來存放資料字典資訊以及一些內部資料結構的記憶體空間大小，所以當我們乙個mysql instance中的資料庫物件非常多的時候，是需要適當調整該引數的大小以確保所有資料都能存放在記憶體中提高訪問效率的。
這個引數大小是否足夠還是比較容易知道的，因為當過小的時候，mysql 會記錄 warning 資訊到資料庫的 error log 中，這時候你就知道該調整這個引數大小了。
innodb_log_buffer_size （global）這是 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 已經完成了磁碟同步。
innodb_max_dirty_pages_pct （global）這個引數和上面的各個引數不同，他不是用來設定用於快取某種資料的記憶體大小的乙個引數，而是用來控制在 innodb buffer pool 中可以不用寫入資料檔案中的dirty page 的比例（已經被修但還沒有從記憶體中寫入到資料檔案的髒資料）。這個比例值越大，從記憶體到磁碟的寫入操作就會相對減少，所以能夠一定程度下減少寫入操作的磁碟io。
但是，如果這個比例值過大，當資料庫 crash 之後重啟的時間可能就會很長，因為會有大量的事務資料需要從日誌檔案恢復出來寫入資料檔案中。同時，過大的比例值同時可能也會造成在達到比例設定上限後的 flush 操作「過猛」而導致效能波動很大。
上面這幾個引數是 mysql 中為了減少磁碟物理io而設計的主要引數，對 mysql 的效能起到了至關重要的作用。
—eof—
按照 mcsrainbow 朋友的要求，這裡列一下根據以往經驗得到的相關引數的建議值：
MySQL資料庫效能優化之快取引數優化
hosted on dreamhost 可以通過我的折扣碼imysqler獲得優惠折扣 在平時被問及最多的問題就是關於 mysql 資料庫效能優化方面的問題，所以最近打算寫乙個mysql資料庫效能優化方面的系列文章，希望對初中級 mysql dba 以及其他對 mysql 效能優化感興趣的朋友們有所...
MySQL 資料庫效能優化之快取引數優化
mysql 資料庫效能優化之快取引數優化 在平時被問及最多的問題就是關於 mysql 資料庫效能優化方面的問題，所以最近打算寫乙個mysql資料庫效能優化方面的系列文章，希望對初中級 mysql dba 以及其他對 mysql 效能優化感興趣的朋友們有所幫助。這是本系列的第一篇文章 mysql 資料...
MySQL 資料庫效能優化之快取引數優化
在平時被問及最多的問題就是關於 mysql 資料庫效能優化方面的問題，所以最近打算寫乙個mysql資料庫效能優化方面的系列文章，希望對初中級 mysql dba 以及其他對 mysql 效能優化感興趣的朋友們有所幫助。這是 mysql資料庫效能優化專題 系列的第一篇文章 mysql 資料庫效能優化之...