为什么新增索引后查询反而变慢了
不是所有字段都适合加索引，
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% 就该审视索引有效性
索引不是越多越好，而是让每一条都承担明确的查询负载。最容易被忽略的是：没有定期用真实查询流量反向验证索引价值，只靠“感觉”或“历史习惯”保留它们。
