MySQL中MyISAM引擎及InnoDB引擎的緩存優化設計

MyISAM引擎中，爲了提升io效率以及讀取效率，將對磁盤頻繁讀取的索引數據加載至內存中操做。

MyISAM設計了一個在存放在內存中的索引緩衝池Key Cache。Key Cache只緩存索引數據，經過LRU算法將讀取頻繁的索引加載到Key Cache中來。

經過系統變量 key_buffer_size 來控制Key Cache的大小，這個變量關乎到緩存的性能。

 

InnoDB引擎中，一樣設置了緩存池buffer pool，與MyISAM有所區別的是，buffer pool不單單緩存了索引數據，同時還緩存了表數據。

這樣的緩衝池同時也帶來了不少問題：緩存中的數據如何與磁盤上的數據保持一致，緩存中的數據支不支持修改更新操做，以及與日誌記錄模塊的同步等等問題。

要解決這些問題帶來的操做時繁瑣的，可是相比於總體性能的提高，也是值得的：硬盤的存取速度與內存的速度更本不是一個數量級的，經過內存來讀取數據，能夠大大的提升數據庫的總體性能。

MySQL官方文檔這樣建議，除了用於系統運行的內存外，剩餘的內存建議儘量大的設置buffer pool。這樣一來有着大容量的buffer pool，在實際應用上的表現更像與一個in-memory database，相比於對磁盤的讀寫速度，讀寫性能簡直就是巨大的提高。

這一切固然基於讀取數據在buffer pool的命中率上面，修改更新等操做會改變buffer pool的一些數據，經過LRU算法更新，將buffer pool的命中率維持在一個比較高的水平。

 

還有一個問題就是怎麼將buffer pool中的數據同步到磁盤。想一想若是更新一次buffer pool就寫一次磁盤，那這樣子的效率和直接讀寫磁盤並無提升多少，這裏就須要設計出同步策略來解決這個問題。

InnoDB是事務安全的，修改buffer pool的數據後，同時還要將此操做記錄在事務日誌中去。這裏對buffer pool的修改操做後，並無直接將數據同步到磁盤，而是將此操做記錄到事務日誌文件中去。這裏又有一個疑問，爲何不將數據寫到磁盤的表數據文件裏去，而是寫到磁盤的事務日誌文件去呢，一樣是磁盤寫操做，有何不一樣？

這裏涉及到磁盤尋道讀寫問題，學過計算機組成原理的就知道了，磁盤讀寫能夠分爲兩種：順序讀寫以及隨機讀寫，若是爲隨機讀寫，將要花必定的時間用於磁頭尋址上，若是爲順序讀寫，則是連續的將數據寫入磁面，磁頭尋址操做不多。這兩種讀寫方式的效率也可見區別甚大

事務日誌文件是InnoDB引擎申請連續物理空間的固定大小的一個文件，對日誌文件的讀寫基本上是順序讀寫，尋址操做甚少。

而buffer pool中的表數據多而複雜：多個表的數據文件在磁盤中的存儲空間是不一樣的，具備隨機性，若每次更新buffer pool中的數據到磁盤，每次操做的表空間表現出隨機性，對磁盤的讀寫也是隨機的，這樣以來頻繁的尋址讀寫操做，將使磁盤處於一個繁忙隨機讀寫狀態。

因此buffer pool的策略也使得總體io性能獲得了提高。

 

轉載請註明出處：http://www.cnblogs.com/iamsupercp/  ,謝謝合做