普通索引和唯一索引 查询性能差异
除非必须由数据库强制执行唯一性约束，否则从性能角度出发，普通索引通常是更好的选择。
1. 查询性能：差距微乎其微
假设你要查询where k=5的记录 ：
普通索引：查找到第一个满足条件的记录后，需要查找下一个，直到遇到第一个不满足条件的记录为止 。
唯一索引：由于定义了唯一性，查到第一个满足条件的记录后就会停止检索 。
为什么性能差距微乎其微？
InnoDB 是以数据页（默认 16KB）为单位进行读写的 。当找到目标记录时，整个数据页通常已经在内存中了 。普通索引多做的那一次“查找和判断”仅仅是内存中的指针寻找和计算，对于现代 CPU 来说，这种开销可以忽略不计 。
2. 更新性能：Change Buffer 的降维打击
这是两者真正的分水岭，理解这个概念需要先了解change buffer机制 。
什么是 Change Buffer？
当需要更新一个数据页时，如果该页不在内存中，InnoDB 会将更新操作缓存在 change buffer 中，而不需要立即从磁盘读入数据页 。等下次查询访问该页时再进行merge（合并操作） 。这减少了随机磁盘访问，提升了执行速度 。
为什么唯一索引用不了它？
唯一索引：每次更新必须判断是否违反唯一性约束 。这要求必须将数据页读入内存进行检查，既然页都读进来了，直接更新内存即可，没必要使用 change buffer 。
普通索引：不需要即时检查，可以完美利用 change buffer 减少磁盘 IO 。
更新场景对比
当更新的目标页不在内存中时 ：
唯一索引：必须进行一次随机磁盘 IO将数据页读入内存，判断冲突后再写入 。
普通索引：直接记录在 change buffer 中，语句执行即刻结束，成本极低 。
3. Change Buffer 与 Redo Log 的区别
这两个机制都利用了WAL（预写日志）策略来提升性能，但侧重点不同 ：
| 机制 | 主要目的 | 提升方式 |
|---|---|---|
| Redo Log | 节省随机写磁盘的 IO 消耗 | 将随机写转化为磁盘顺序写 |
| Change Buffer | 节省随机读磁盘的 IO 消耗 | 避免在更新时立即读取不在内存中的数据页 |
4. 实践建议
在实际业务场景中，如何选择索引建议参考以下标准：
写多读少业务：如账单、日志系统，此时 change buffer 收益最大，应优先使用普通索引。
写后立刻读业务：如果写入后马上就会查询，会频繁触发 merge 操作，change buffer 反而会增加维护代价，此时应考虑关闭它 。
机械硬盘场景：change buffer 对机械硬盘的性能提升极为显著，建议尽量使用普通索引并调大 change buffer 空间 。
归档库场景：历史归档数据通常已确保唯一，可以将唯一索引改为普通索引以提高归档写入效率。
5. 如果某次写入使用了change buffer机制，之后主机异常重启，是否会丢失change buffer和数据。
简单直接的回答是：只要事务已经提交，数据就不会丢失。
这里有一个常被误解的点：Change Buffer 不仅仅是“内存缓存”。
- 在磁盘上，Change Buffer 也是有实体的，它被持久化在系统表空间（ibdata1）中。
- 当内存中的 Change Buffer 积累到一定程度，或者系统空闲时，InnoDB 会将其内容刷入磁盘上的 Change Buffer B+树中。
此外，在 InnoDB 中，Change Buffer 的操作并不是孤立的。当你执行一条更新指令且命中 Change Buffer 时，MySQL 会执行以下两个关键动作：
- 在内存中的Change Buffer记录下这次修改。
- 同时将这个修改操作记录到Redo Log中。
如果主机此时异常重启，内存中的 Change Buffer 确实会消失，但由于 Redo Log 已经持久化到了磁盘：
- 重启后：InnoDB 会读取磁盘上的 Redo Log 进行恢复。
- 重做操作：Redo Log 中记录了对 Change Buffer 所在页面（属于系统表空间）的修改。InnoDB 会通过重放这些日志，在内存中“重建”出之前的 Change Buffer，或者直接将修改应用到对应的数据页。
- 最终一致性：这样就保证了即使由于非顺序 IO 导致数据页没来得及更新到磁盘，逻辑上的修改依然存在。