MySQL 索引优化的五个要点

在关系型数据库中，索引是提升查询性能最有效的机制之一。MySQL 基于 B+ 树实现的索引，能够在对数时间内完成范围扫描与随机查找，但如果设计不当，索引也会带来写入放大、额外内存消耗和查询走错执行计划等问题。下面总结 MySQL 索引优化的五个要点，帮助我们在日常开发中做出更稳妥的选择。

第一，优先为高频查询条件列建立索引，并遵循最左前缀原则。对于联合索引 (a, b, c)，优化器只能利用 a、(a, b) 或 (a, b, c) 作为查询前缀，单独以 b 或 c 开头的条件无法命中该索引。设计联合索引时，应把区分度最高、等值过滤最多的列放在前面，范围查询列放在后面。

第二，用覆盖索引减少回表。当查询所需的所有列都包含在索引中时，MySQL 可以直接从索引叶子节点读取数据，避免再访问聚簇索引。对 "SELECT id, email FROM users WHERE email = ?" 这类场景，建立 (email, id) 的联合索引即可实现覆盖。覆盖索引能显著降低随机 I/O，但在宽表场景下要注意索引体积膨胀。

第三，提升列的区分度并避免过长前缀。对 varchar 类型建立索引时，如果列值普遍较长且前缀区分度已经足够，可以使用 CREATE INDEX idx_name ON t(col(10)) 只索引前 N 个字节，从而减小索引页大小、提升缓存命中率。区分度可以用 SELECT COUNT(DISTINCT col)/COUNT(*) 评估，区分度越低，索引的过滤效果越差。

第四，关注索引选择性并与数据分布匹配。当查询条件命中数据的比例过高（例如 gender 列只有两个值），优化器往往会放弃索引而改用全表扫描。遇到这类低选择性列，要么将其作为联合索引的靠后部分配合高区分度列一起过滤，要么就不单独建索引。同时，定期执行 ANALYZE TABLE 更新统计信息，避免因统计信息过期导致执行计划劣化。

第五，用 EXPLAIN 验证索引是否真正被使用，并警惕隐式类型转换与函数导致索引失效。例如对索引列加上函数 like WHERE YEAR(create_time) = 2026，或在字符串索引列上传入数字，都会使优化器回退到全表扫描。正确的做法是让查询条件与索引列的原始类型和表达式保持一致，必要时通过改写 SQL 或增加合适的函数索引来命中索引。

综合来看，索引不是越多越好。每新增一个索引，INSERT/UPDATE/DELETE 都需要维护对应的 B+ 树，写入性能会下降。合理的做法是以慢查询日志和性能剖析为起点，只为核心查询路径建立索引，用 EXPLAIN 确认执行计划，再用覆盖索引和最左前缀原则打磨细节，并在数据量增长后定期复核索引的使用率与区分度。