MySQL 普通索引和唯一索引有什么区别？Change Buffer 为什么不能随便用于唯一索引？

知识点详解：一个要先确认不重复，一个可能先记下改动

冷页为什么影响写入成本？

假设要往一个二级索引页插入记录，但这个页不在内存缓存里。为了修改它，可能先需要从存储读入。

对于某些符合条件的普通二级索引修改，Change Buffer 可以先记录需要发生的变化。以后页被读入等时机，再合并这些修改。

这样是在调整访问时机，并不是跳过维护索引，也不是已经把最终索引页写完。后续合并仍有成本，相关机制见 MySQL Change Buffer 说明。

图：延后修改，还需要合并。

唯一性检查为什么不能想当然地推迟？

如果用户名必须唯一，插入一个值之前，需要知道是否已经存在与它冲突的记录。

当前不知道冷页上有什么，就先接受任意重复值，再等以后合并时发现冲突，这不能满足正常的唯一性要求。所以，唯一索引的处理需要把约束检查放进分析里。

批量导入等受控场景可能存在关闭检查的专门配置，不能把那个特殊前提，写成日常业务可以随便使用的优化。数据必须有可靠保证，恢复检查也不会神奇地替你修复所有错误。

MySQL 8.4 为什么不能沿用旧默认值？

很多旧资料会直接说“普通索引可以利用 Change Buffer”，却省略它有没有开启。

在 8.4，默认 none 意味着不能直接按默认开启的假设评价写入。如果要讨论某种优化效果，至少先确认实际版本、配置以及修改是否满足使用条件。

这也是为什么同一道面试题，不能只背“普通索引写入更快”。如果页本来就在内存里，或者缓冲关闭，前面的解释就不是这次性能差异的主要依据。

延后工作，也可能在后面形成压力

如果改动持续积累，合并会使用资源，并影响后续读取等过程。减少一次即时冷页读取，不等于整个系统没有付出代价。

因此，评估时需要对照写入延迟、读取延迟、缓存命中和合并压力。在自己的负载上测，不拿一个没有说明配置的吞吐数字当普遍结论。

约束不能被性能口号替代

如果业务真的要求用户名或其他键唯一，数据库约束是重要的完整性保证。不能因为普通索引可能有写入收益，就把唯一索引直接改掉。

应用层“先查一下再插入”，在并发时也会遇到竞争。选索引先满足数据正确性，再考虑优化实现。

本题解释 InnoDB 条件，没有伪造 TS、Python 侧的索引实现或数据库压测。

面试官继续追问

页都在缓存里，Change Buffer 还是主要优势吗？

不应这么断言。它针对的关键前提之一是目标页不在缓存中，分析要先检查前提。

要不要统一打开它？

没有统一答案。核对版本、硬件、负载与支持范围，再在测试环境比较。不要在生产上仅凭面试口诀改全局配置。

面试速记卡

• 唯一索引：先满足唯一约束，正常写入要检查冲突。
• Change Buffer：符合条件的冷二级索引页修改，可以延后合并。
• 非通用：不是主键、所有索引、所有操作都适用。
• 版本：MySQL 8.4 默认 innodb_change_buffering=none。
• 取舍：正确性不退让，性能必须带配置与负载。