一、MySQL中，為什么還要change buffer只作用于二級索引

先說一下普通一個數據修改的過程（這里不涉及到改主鍵索引或少數索引B+樹結構的，就說改普通字段的值）

名列前茅步：INNODB要修改一個數據時，先判斷內存（Buffer Pool）中有沒有這個數據，有的話則直接修改內存。沒有的話，先從磁盤中讀到內存，再進行修改（先假設是這樣）。

第二步：寫redo log，將事務的狀態標位prepare

第三步：寫binlog

第四步；將redo log中事務的狀態標位commit

到這里，一個事務已經結束了，但是你會發現，數據壓根就沒落盤，只在Buffer Pool進行了相應的修改。

而這些在內存中的數據（臟頁）會在一段時間后因為某些原因才會被刷到磁盤中，那在這中間還沒有刷到磁盤的過程中，則有可能發生斷電，那還沒有保存到磁盤中的buffer pool中的數據也就丟了，而redo log的作用，就是斷電重啟之后，用來恢復這部分的數據。（在我看來，redo log的作用僅此而已，有誤的話可以指正）

再回過頭看名列前茅步：如果是普通索引（非少數索引），哪怕內存中沒有這條數據，直接保存修改就行了，連去磁盤讀取出這條數據這一步都不需要，節省了磁盤IO的時間。也就是上面說的流程中的名列前茅步其實應該改為：如果僅僅修改了普通索引的話，內存中若有這條數據，則直接修改，若沒這條數據，則先將修改的操作寫到change buffer中。

回到問題：change buffer是做什么的？

答：當然是為了提高效率的，但是有一定的局限性，基本上只能用在：數據在磁盤中而不在內存中，而這次修改不會涉及到改動主鍵索引以及少數索引的結構 的情況之下。也就是優化了上面流程中的名列前茅步。

第二個問題：我沒太理解是什么意思，不過我上面一段的描述或許能夠解釋？

問：change buffer似乎只能作用于二級索引？

答：什么時候不能夠用change buffer呢？如果涉及到修改聚簇索引（主鍵索引）的結構時，比如新增一條字段，或者直接把主鍵的值給改了，類似于這樣的操作，當然是用不了change buffer的。因為為了主鍵少數性校驗，必須先去磁盤中讀有沒有這條數據（或者內存中有對應的數據頁也可以），才能進行更新，比如插入了一條id=5的數據，那當然要去判斷一下有沒有id = 5的數據，才能進行插入了，此時change buffer也就沒有意義了。

延伸閱讀：

二、為什么要持久化連接

這和 web 服務器的工作方式有關。web 服務器可以通過三種方法來利用 PHP 生成 web 頁面。

名列前茅種方法是將 PHP 自以為 CGI“包裝器”用作一個單獨運行的語言解釋器(CGI Wapper)。當以這種方法運行時，PHP 會為向 web 服務器的每個 PHP 頁面請求創建并銷毀 PHP 解釋器的時候實例。由于其會隨每個請求的結束而銷毀，因此其獲取的任何資源（例如指向 SQL 數據庫服務器的鏈接）都會在銷毀時關閉。在這種情況下，不會從使用持久連接中獲得任何好處——因為根本不會持久。

第二，也是最流行的方法是把 PHP 用作多進程 web 服務器的一個模塊，這種方法目前只適用于 Apache。多進程的服務器通常有一個父進程和一組子進程協調運行，子進程負責提供網頁的工作。每當接收達到客戶端提出請求時，該請求會傳遞給尚未給其它客戶端提供服務的某個子進程。這也就是說當相同的客戶端第二次向服務端發出請求時，它將有可能由與名列前茅次不同的某個子進程提供服務。在開啟了一個持久連接后，所有請求 SQL 服務的后繼頁面都能夠重用與 SQL 服務器建立的相同連接。

最后一種方法是將 PHP 用作多線程 web 服務器的插件。目前 PHP 支持 WSAPI 和 NSAPI（在 Windows 上），允許 PHP 作為 Netscape FastTrack（iPlanet）、Microsoft 的 Internet Information Server (IIS) 和 O’Reilly 的 WebSite Pro 等多線程服務器的插件使用。該行為與前面描述的多過程模型相同。