在数据库索引设计中，唯一索引与普通索引的性能差异是开发者经常争论的话题。很多人在建表时倾向于使用普通索引，理由是唯一索引有额外校验开销；也有人坚持唯一索引更利于优化器。那么，唯一索引与普通索引的性能差异到底有多大？在什么场景下应该选择哪一种？本文从InnoDB存储引擎的索引结构出发，结合执行计划和写入路径，给出可操作的判断依据。
从B+树结构看查询性能：几乎无差别
在InnoDB中，唯一索引和普通索引都使用B+树结构。对于等值查询，唯一索引由于约束了键值不重复，优化器在找到第一条匹配记录后即可停止扫描；而普通索引在找到第一条匹配记录后，还需要继续扫描下一条，以确认是否还有重复键值。但这个差异在多数场景下可以忽略：因为普通索引的叶子节点按顺序排列，扫描下一条记录的成本极低，通常只多一次指针移动和比较操作。
对于范围查询，两者的执行计划基本相同，都是通过索引定位到起始位置后顺序扫描。唯一索引的约束并不影响范围扫描的方式。因此，在查询性能上，唯一索引与普通索引的差异通常小于1%，尤其在数据量不大时几乎可以忽略。真正影响查询性能的是索引的字段选择、顺序和覆盖情况，而非是否唯一。
写入性能：唯一性检查带来的额外开销
当执行INSERT或UPDATE时，唯一索引需要额外进行唯一性检查。在InnoDB中，这个检查通过索引查找实现：插入前需要定位到插入位置，并检查相邻记录是否冲突。对于普通索引，则直接插入新记录，无需检查。因此，在批量写入场景下，唯一索引的写入开销会略高于普通索引，尤其是当索引字段较长或表数据量大时，唯一性检查需要额外的B+树查找。
然而，这种差异在大多数应用中可以接受。根据经验，唯一索引的写入性能大约是普通索引的90%-95%，具体取决于数据分布和索引大小。如果写入是系统的瓶颈，且业务上确实不需要唯一约束，那么选择普通索引可能更合适；但如果需要保证数据唯一性，则必须使用唯一索引，不能为了性能牺牲正确性。
存储占用：唯一索引与普通索引的物理差异
在InnoDB中，索引数据以B+树形式存储，叶子节点包含索引键值和主键值。唯一索引和普通索引的存储结构基本相同，唯一区别是唯一索引的键值不允许重复，这意味着在叶子节点中不会出现重复的键值条目。对于普通索引，如果存在大量重复键值，叶子节点会存储多个相同的键值，这会增加存储空间和扫描时间。
举个例子，如果在一个包含100万行的表中，某个普通索引字段有10万个重复值，那么普通索引的叶子节点会多出约10万条记录，而唯一索引则不会。因此，从存储空间角度看，唯一索引可能更节省空间，尤其是在高基数字段上。但基数过低（如性别字段）时，普通索引的重复值问题会更严重，此时唯一索引的优势更明显。
优化器行为：唯一索引的额外优势
MySQL优化器在处理唯一索引时，可以利用其唯一性进行一些优化。例如，在JOIN操作中，如果被驱动表的连接列是唯一索引，优化器可以确定最多只返回一行，从而采用更高效的执行计划。此外，在某些情况下，唯一索引可以帮助优化器消除重复行的扫描，减少回表次数。
但需要注意的是，这些优化在普通索引上也可能通过其他方式实现，例如使用覆盖索引或索引下推。因此，唯一索引在优化器层面的优势并非绝对，需要根据具体查询模式来判断。
实践建议：如何选择索引类型
综合以上分析，可以得出以下选择原则：
- 如果业务上需要确保字段值的唯一性（如用户邮箱、订单号），必须使用唯一索引，即使有轻微写入开销。
- 如果字段本身基数很高（如UUID），且没有唯一性要求，普通索引和唯一索引性能差异极小，可以随意选择。
- 如果字段基数较低（如状态字段），普通索引可能导致大量重复值，增加存储和扫描成本，此时应考虑使用唯一索引或设计复合索引。
- 在批量写入场景中，如果写入性能是瓶颈，且业务允许暂时不校验唯一性，可以考虑使用普通索引，并在应用层实现唯一性检查。
此外，索引设计应结合查询模式。例如，对于经常需要排序或分组的字段，索引的选择会影响排序性能。唯一索引和普通索引在排序上的行为基本一致，但唯一索引可能提供更紧凑的索引结构，从而提升缓存效率。
常见误区与失败条件
一个常见误区是认为唯一索引一定比普通索引慢，因此所有字段都用普通索引。实际上，唯一索引在查询和存储上可能更有优势，尤其是在高基数场景。另一个误区是忽略复合索引中唯一性的作用。例如，在复合索引(a, b)中，如果只对a列设置唯一约束，那么b列可以重复，此时唯一索引的性能与普通索引差异不大，但约束范围需明确。
失败条件：如果唯一索引字段允许NULL，则唯一性约束不生效（InnoDB允许多个NULL），此时唯一索引退化为普通索引，性能差异消失。另外，在使用前缀索引时，唯一性无法保证，因此不应使用前缀索引作为唯一约束。
总结
唯一索引与普通索引的性能差异主要体现在写入时的唯一性检查，以及在高重复值场景下的存储和扫描效率。在查询性能上，两者几乎无差别。实际应用中，应根据业务需求和数据特征选择索引类型，而不是盲目追求性能。对于需要唯一性的字段，应使用唯一索引；对于高基数字段，两者均可；对于低基数字段，应谨慎设计索引，避免重复值过多。
最后，索引优化是一个系统工程，建议结合执行计划分析和实际业务场景进行调优。可参考本站关于MySQL InnoDB存储引擎索引原理与B+树慢查询优化实战和数据库索引失效的常见原因与排查方法等文章，获得更多索引优化技巧。
参考资料
延伸阅读