新增索引后查询变慢是因为低基数字段建索引无效、索引维护开销大、未遵循最左前缀原则、统计信息过期或索引冗余；应评估选择性、监控使用情况、合理设计联合索引顺序并定期清理无用索引。
为什么新增索引后查询反而变慢了
不是所有字段都适合加索引，WHERE 条件里高频出现、选择性高（如 user_id）、且数据分布均匀的字段才值得建索引。如果对 gender 或 status 这类低基数字段建索引，MySQL 可能直接放弃使用，甚至因维护索引开销导致 INSERT/UPDATE 明显变慢。
常见错误现象：EXPLAIN 显示 type=ALL（全表扫描）或 key=NULL，但你以为索引已生效；或者 SHOW INDEX FROM table_name 看到一堆 idx_*，却没人知道每个索引对应哪条业务 SQL。
- 建索引前先用
SELECT COUNT(DISTINCT column_name) / COUNT(*)估算选择性，低于 0.01 的谨慎考虑 - 复合索引要遵循最左前缀原则，
(a,b,c)能覆盖WHERE a=1 AND b=2，但无法用于WHERE b=2 AND c=3 - 避免对
TEXT、BLOB字段直接建普通索引，改用前缀索引（如INDEX idx_title (title(50))），并确认业务查询真会用到前 50 字符
如何识别并删除无用索引
MySQL 本身不自动记录索引使用频次，但 5.6+ 版本可通过 sys.schema_unused_indexes 视图快速定位长期未被优化器选用的索引（需开启 performance_schema）。更稳妥的方式是结合慢查询日志 + pt-index-usage 工具回放真实流量。
注意：主键和唯一约束生成的索引不能删；外键列上的索引也需确认关联表操作是否依赖它。
- 执行
SELECT * FROM sys.schema_unused_indexes前，确保performance_schema已启用且采集周期覆盖至少一个业务高峰 - 删除前用
SELECT COUNT(*) FROM information_schema.STATISTICS WHERE table_name = 'your_table' AND index_name = 'idx_xxx'核对索引是否存在，防止误删 - 生产环境删索引必须在低峰期操作，且提前在从库验证影响；
DROP INDEX idx_name ON table_name是 DDL，会锁表（8.0+ 支持ALGORITHM=INPLACE，但仍建议测试）
联合索引设计时容易忽略的顺序问题
字段顺序不是按 SQL 出现顺序排，而是按过滤强度 + 排序需求综合判断。比如用户列表页常查 WHERE status=1 ORDER BY created_at DESC，那么 (status, created_at) 比 (created_at, status) 更有效——前者能先快速定位 status=1 的数据块，再在该子集内排序；后者则需扫描大量 created_at 数据才能筛出 status=1 的行。
- 等值查询字段（
=、IN）放前面，范围查询字段（>、BETWEEN）放最后，排序字段可跟在范围字段后（如(a, b, c)支持WHERE a=1 AND b > 10 ORDER BY c） - 避免为同一组字段建多个顺序不同的联合索引，例如已有
(user_id, order_time)，就别再建(order_time, user_id)，除非有明确的WHERE order_time > ? ORDER BY user_id场景 - 用
EXPLAIN FORMAT=JSON查看used_columns和key_length，确认优化器实际用了索引的几列
监控索引膨胀与统计信息过期
索引文件本身会占用磁盘空间，且随着数据变更，INFORMATION_SCHEMA.INNODB_SYS_INDEXES 中的 size 字段可能远超预期。更隐蔽的问题是统计信息未更新：当表数据量突增（如批量导入百万行）后，优化器仍按旧的行数估算执行计划，可能导致跳过本该使用的索引。
- 定期检查
SELECT table_name, index_name, stat_value FROM mysql.innodb_index_stats WHERE database_name='your_db'，对比stat_value与实际行数偏差是否超过 20% - 手动更新统计信息用
ANALYZE TABLE table_name，但注意它会短暂锁表；8.0+ 可设innodb_stats_auto_recalc=ON并调小innodb_stats_persistent_sample_pages加速采样 - 用
SELECT data_length, index_length FROM information_schema.TABLES WHERE table_schema='your_db' AND table_name='your_table'监控索引大小占比，超过 50% 就该审视索引有效性
索引不是越多越好，而是让每一条都承担明确的查询负载。最容易被忽略的是：没有定期用真实查询流量反向验证索引价值，只靠“感觉”或“历史习惯”保留它们。
