理解无用索引及其对查询性能的影响
在 MySQL 数据库中，索引是提升查询速度的关键工具，但并非所有索引都会被实际查询使用。无用索引会带来额外的维护成本、写入开销以及磁盘空间的消耗，从而降低整体系统的吞吐能力。通过系统化地识别并清理无用索引，可以在不影响正确性的前提下显著提升查询性能和写操作的响应速度。
本文围绕 MySQL 索引优化实践，即如何高效清理无用索引以提升查询性能，强调基于数据的判断与安全可控的执行流程。核心目标是让热路径的查询获得更稳定的响应，同时将冷路径的维护成本降到最低。
为何需要定期清理无用索引
当表上存在冗余或未被命中命中的索引时，数据库在更新、插入和删除时需要额外维护这些索引结构，导致写放大效应，并增加磁盘 I/O 与缓存压力。定期清理无用索引可以直接降低写入延迟、减少锁争用，并为热查询腾出更多资源。
此外，过多的索引还可能干扰优化器的选择，产生次优的执行计划。通过清理策略，可以让优化器更容易命中高效索引，从而实现持续的查询性能提升。清理工作应与实际业务负载对齐，避免過度极端化的删改导致不可预期的回退成本。
定义无用索引及其影响
通常将“无用索引”界定为在一定时间窗口内未被使用、或在实际查询中对常见筛选条件和排序条件未产生显著命中效果的索引。判定依据包括命中率、使用分布、查询计划的实际执行情况以及对写入路径和维护成本的综合评估。
需要注意的是，某些索引可能在偶尔的边缘查询中有用，但总体使用率极低。在清理前应通过多轮验证、回滚演练以及对关键业务查询的回归测试来确保变更的安全性。避免一刀切删除，建议保留核心工作负载所依赖的索引，并将候选清理分阶段实施。
数据驱动的识别流程
收集工作负载与基线
要判断哪些索引属于无用，需要先建立工作负载的基线。通常优先收集慢查询占比、命中率、以及对不同查询的执行计划信息。通过基线可以回答以下问题：哪些查询模式最常出现？哪些索引在实际执行中未被使用？基线越完整，后续的清理决策就越可靠。建立可重复的基线是持续优化的前提。
在基线阶段，可利用慢查询日志、性能模式数据以及系统视图汇总信息，形成候选清理清单。为了便于团队协同，建议把基线指标与时间窗绑定（如最近7天、最近30天等），便于对比清理前后效果。数据驱动的清理才具备可追溯性。
使用工具与查询分析
在识别无用索引时，工具与查询分析同等重要。常用方法包括结合性能分析视图、统计信息，以及专用工具的辅助报告。一个广泛使用的做法是利用 Percona Toolkit 的 pt-index-usage 等工具，基于实际慢查询或通用日志分析索引命中情况，并输出候选清理名单。
除了外部工具外，MySQL 自带的执行计划分析也很重要。通过对常见查询执行 EXPLAIN 或 EXPLAIN ANALYZE 的对比，可以判断当前查询是否被最优索引覆盖，以及是否存在不必要的索引参与计划的情况。结合这两类信息，可以形成清晰的候选清理列表。
-- 示例：查看某表的常见查询计划
EXPLAIN SELECT t.id FROM t WHERE t.user_id = ?;-- 或者使用 EXPLAIN ANALYZE 以获取真实执行时间
EXPLAIN ANALYZE SELECT t.id FROM t WHERE t.user_id = ?;
实操：高效清理无用索引
标记候选与风险评估
在正式删除前，先将候选清理项标记出来，并进行全面的风险评估。对每个候选索引，记录其历史命中情况、对写入的影响评估，以及对关键业务查询的潜在影响。建立回滚策略与时间窗内的回溯验证，确保遇到性能回退时可以快速恢复。
建议采用分阶段的清理方式：先在非高峰时段对小表进行试点，再逐步推广到高价值表。对每一次清理，留存可回溯的监控数据，以便对比清理前后差异。逐步推进能降低业务风险。
-- 示例：在分阶段清理前，备份相关表结构与数据
-- 你可以先导出该表的现有索引列表，便于对比回滚
SHOW INDEX FROM orders;
若你使用了外部工具进行索引使用分析，可以在此阶段导出候选清理清单，并将清单导入变更计划文档中，确保所有相关团队对变更有清晰共识。文档化的变更计划有助于快速回滚与审计。
执行清理与回滚策略
清理无用索引的核心操作是删除已确认不会影响业务热路径的索引。在执行删除前，务必做好备份，并尽量通过在线DDL方式降低停机风险。常用的删除方法包括以下两种形式：
-- 方法一：通过 ALTER TABLE 清理索引（推荐）
ALTER TABLE orders DROP INDEX idx_customer_id;-- 方法二：使用 DROP INDEX 语句（MySQL 兼容性写法之一）
DROP INDEX idx_customer_id ON orders;
删除后，务必对关键查询进行回归测试，使用实际工作负载的典型查询进行对比。若出现性能下降或查询计划回退，按照回滚策略快速恢复被删除的索引，并重新评估清理范围。备份与回滚是任何删除操作的第一原则。
验证与持续优化
验证查询计划与性能变化
删除无用索引后，必须通过对照基线的查询计划和实际执行时间来验证影响。可以使用 EXPLAIN、EXPLAIN ANALYZE 等工具，检查热路径查询是否仍然使用高效的索引，以及整体执行时间是否有所改善。若某些查询的性能下降，可能需要重新调整索引策略或对相关列添加新的覆盖索引。
持续记录关键指标，例如查询平均响应时间、TPS、慢查询比例以及写入延迟等，以便在未来的版本迭代中再次评估索引结构的合理性。量化指标是持续优化的关键。
-- 示例：使用 EXPLAIN ANALYZE 验证某查询的实际执行情况
EXPLAIN ANALYZE SELECT o.id, o.total
FROM orders o
WHERE o.customer_id = 123 AND o.status = 'PAID';
持续监控与自动化
索引优化是一个持续的过程，需要把监控和自动化作为常态化工作。可以设置定期的索引使用报告、对慢查询日志的持续分析，以及对核心表的滚动基线比较。通过自动化脚本把 pt-index-usage、EXPLAIN、以及查询响应时间的结果聚合到统一的监控仪表盘，可以实现“自我诊断”的能力。
# 示例：每日运行一次索引使用报告并推送到监控系统
0 2 * * * /usr/bin/pt-index-usage /var/log/mysql/slow.log --output json > /var/log/index_usage_daily.json
在持续监控阶段，若出现新的热查询模式或工作负载变化，应重新评估现有索引结构，必要时进行增量化的索引调整。动态的负载变化要求灵活的索引策略，避免因历史基线过时而错删有用的索引。
