MySQL 索引并非越多越好，过多会降低写入性能、增加存储开销并干扰查询优化；应基于慢日志和 EXPLAIN 分析，优先覆盖高频 WHERE、JOIN、ORDER BY/GROUP BY 及覆盖查询字段，清理冗余索引，控制单表有效索引数在 5 个以内。
MySQL 索引不是越多越好，过多索引反而会拖慢写入性能、增加存储开销，并可能干扰优化器选择最优执行计划。
索引对写操作有明显负面影响
每次 INSERT、UPDATE、DELETE 操作，MySQL 不仅要修改数据行，还要同步更新所有相关索引。索引越多，维护成本越高。例如一张日志表每秒插入 1000 条记录，若建了 5 个二级索引，实际写入耗时可能比只有主键索引时高出 3 倍以上。
- 单条 INSERT 可能触发多个 B + 树的分裂和页面重组织
- UPDATE 若涉及索引列，会同时修改聚簇索引和对应二级索引
- 大量索引让缓冲池（innodb_buffer_pool）更难缓存热数据，降低整体命中率
优先保障高频查询和连接字段的索引覆盖
应基于真实慢查询日志（slow_query_log）和 EXPLAIN 分析结果来建索引，而不是凭经验预设。重点覆盖：
- WHERE 条件中频繁出现的列组合（注意最左前缀原则）
- JOIN ON 子句中的关联字段（两边都建议加索引）
- ORDER BY 和 GROUP BY 涉及的列（避免 filesort 或 temporary 表）
- SELECT 中需要覆盖查询（Covering Index）的字段组合
定期清理无效和重复索引
很多表在迭代过程中积累了冗余索引，比如已有索引 (a, b, c)，又单独建了 (a, b) 或 (a)，后者完全被前者包含。可通过以下方式识别：
- 使用 pt-duplicate-key-checker 工具 扫描重复索引
- 查询 information_schema.statistics 筛选相同 table_name + seq_in_index= 1 且 index_name 不同的索引前缀
- 观察 performance_schema.table_io_waits_summary_by_index_usage 中 rows_selected 为 0 的索引
控制单表索引总数，合理设置复合索引长度
一般业务表建议控制在 5 个以内有效索引（不含主键），超 10 个需警惕。对于长文本字段（如 VARCHAR(1000)），避免直接索引全字段：
- 用前缀索引（如 INDEX(title(50))）平衡区分度与空间占用
- 对 JSON 字段慎用虚拟列 + 索引，评估是否真有必要走索引过滤
- 全文检索需求优先考虑 FULLTEXT 索引，而非 LIKE “%xxx%” 配合普通 B + 树
