MySQL中，既有redo log作为WAL，为什么还要change buffer只作用于二级索引

先说一下普通一个数据修改的过程（这里不涉及到改主键索引或少数索引B+树结构的，就说改普通字段的值）名列前茅步：INNODB要修改一个数据时，先判断内存（Buffer Pool）中有没有这个数据，有的话则直接修改内存。

一、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 等多线程服务器的插件使用。该行为与前面描述的多过程模型相同。