MySQL查询稳定性依赖索引优化：①索引字段需出现在WHERE/JOIN/ORDER BY中、区分度高、过滤性强；②组合索引按最左前缀及过滤性排序；③避免在条件中对字段做函数操作；④定期更新统计信息防止执行计划漂移。
MySQL 查询稳定性主要指在高并发、数据量增长或查询条件变化时，查询响应时间保持一致、不出现大幅波动。索引是提升稳定性的核心手段——它减少随机 I/O、避免全表扫描、降低锁竞争，从而让查询执行计划更可预测、资源消耗更平稳。
合理选择索引字段，覆盖高频且过滤性强的条件
稳定性问题常源于某些查询突然变慢，根源往往是优化器在数据分布变化后放弃使用索引，转而走全表扫描。要避免这点，索引字段应优先满足：① 出现在 WHERE、JOIN、ORDER BY 中；② 区分度高（如 user_id > status）；③ 单次查询能过滤掉大部分数据（例如 不要对性别、是否启用等低基数列单独建索引）。建议用 EXPLAIN 检查执行计划，确认 key 列非 NULL、rows 估值合理、没有 Using filesort 或 Using temporary。
组合索引遵循最左前缀原则，并按过滤性排序
多条件查询时，单列索引效果有限，容易触发索引失效。应建立组合索引，字段顺序至关重要：把区分度最高、约束最严格的列放最左。例如查询常为 WHERE category = ? AND created_at > ? ORDER BY score DESC，则推荐索引 (category, created_at, score)。注意：范围查询（>、
避免隐式类型转换和函数操作导致索引失效
即使字段有索引，以下写法也会让索引“沉默”：WHERE CONCAT(name, '') = 'Alice'、WHERE age + 1 = 26、WHERE create_time > STR_TO_DATE('2024-01-01', '%Y-%m-%d')。这些操作迫使 MySQL 对每行计算后再比对，无法利用 B+ 树结构快速定位。应改写为：WHERE name = 'Alice'、WHERE age = 25、WHERE create_time > '2024-01-01'。同时确保字段类型与参数严格一致（如 INT 列不用字符串 '123' 查询）。
定期分析表统计信息，防止执行计划漂移
MySQL 依赖表的统计信息（如索引基数、数据分布）选择执行计划。当数据大量增删后，统计信息可能过期，导致优化器误判，比如该走索引却选了全表扫描。可通过 ANALYZE TABLE table_name 手动更新；也可开启 innodb_stats_auto_recalc = ON（默认开启），让 InnoDB 在表变更超 10% 时自动重算。配合 innodb_stats_persistent = ON 可持久化统计信息，进一步提升计划一致性。
