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+树
