应仅在优化器选错索引且EXPLAIN证实低效（如全表扫描、低区分度索引）时，用FORCE INDEX强制走更优索引；USE INDEX是缩小候选索引范围的建议，IGNORE INDEX用于临时规避问题索引。
什么时候该用 FORCE INDEX 强制走索引
当你明确知道优化器选错了索引，且 EXPLAIN 显示它用了低效索引（比如全表扫描、或走了区分度极低的索引），而你手头有更合适的索引时，才考虑 FORCE INDEX。常见场景包括：
- 表数据量突增后统计信息未更新，优化器误判索引成本
- 联合索引中前导列过滤性极强（如
status = 'paid'+ 时间范围），但优化器却选了只含时间字段的单列索引 - 查询条件匹配覆盖索引，但优化器仍回表——强制走覆盖索引可避免
Using where; Using index变成Using where; Using index condition
⚠️ 注意：FORCE INDEX (idx_name) 后必须跟 WHERE 条件，否则 MySQL 会报语法错误；如果强制的索引根本无法用于该 WHERE 条件（比如没包含任何查询列），查询可能直接变慢甚至锁表加剧。
USE INDEX 是“建议”，不是“命令”
USE INDEX 的作用是缩小优化器的索引候选集，告诉它：“只从这几个里挑，别看别的”。它不保证一定用上，只是减少误选概率。适合这些情况：
- 一张表有 5 个索引，其中 3 个明显和当前查询无关（比如按
create_time建的归档索引），用USE INDEX (idx_status, idx_user_id)能加快优化器决策 - 刚加完新索引，想快速验证它是否比旧索引更优，又不想冒险
FORCE - 开发环境数据量小，优化器倾向全表扫描，但线上数据大，你希望它优先试用某个索引
关键区别：USE INDEX (a,b) 不等于 “用 a 或 b 索引”，而是“从 a 和 b 这两个索引中选一个”；括号里填的是**索引名**，不是列名——填错直接被忽略。
IGNORE INDEX 通常用于“排雷”，不是日常优化手段
绝大多数时候，IGNORE INDEX 是临时救火用的：当某个索引被误建、正在下线、或存在严重数据倾斜（比如某值占 95% 行数），导致优化器反复选它拖垮查询时，可用它绕过。
- 例：有个
idx_is_deleted单列索引，但is_deleted = 0占 99% 数据，优化器仍选它走索引扫描 → 加IGNORE INDEX (idx_is_deleted)强制走更合理的联合索引 - 准备删掉一个索引前，先在关键 SQL 中加
IGNORE，观察一周无性能抖动，再安全删除
⚠️ 风险点：如果忽略的是唯一索引或主键，MySQL 可能退化为全表扫描，且 EXPLAIN 的 key 字段会显示 NULL —— 这不是“没走索引”，是“被你亲手关掉了所有路”。
比加提示更重要的三件事
索引提示是“止痛药”，不是“根治方案”。真正该优先做的：
- 跑
ANALYZE TABLE table_name更新统计信息，很多“选错索引”问题当场解决 - 检查是否缺失覆盖索引：比如
SELECT id, name FROM user WHERE status=1，建INDEX(status, name, id)比任何提示都管用 - 确认查询是否真的需要
SELECT *—— 返回多余字段会破坏覆盖索引效果，让FORCE白费力气
一旦开始依赖 FORCE INDEX，就要警惕：下次表结构变更、MySQL 版本升级、或数据分布变化，都可能让这条“救命语句”变成性能黑洞。
