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/ ,謝謝合作
