USE INDEX 是优化器建议，必须紧贴表名或别名、位于 WHERE 前，语法正确且索引存在、统计信息准确时才可能生效；EXPLAIN 的 key 列显示指定索引名方可确认起效。
USE INDEX 语法必须写在表名后、WHERE前
直接把提示塞进 SELECT 语句里，位置错了就完全不生效。常见错误是把它写成注释、放在 WHERE 后面，或者误加在子查询外层却想影响内层表。
正确写法示例：SELECT * FROM orders USE INDEX (idx_status_created) WHERE status = 'shipped' AND created_at > '2026-01-01';
如果表用了别名，提示必须紧贴别名：FROM orders o USE INDEX (idx_status_created)，而不是 FROM orders USE INDEX (...) o。
多个索引可并列写，用逗号分隔：USE INDEX (idx_a, idx_b)，但优化器只从中选一个——它不是“多索引联合扫描”，只是缩小候选范围。
验证是否真起作用，只看 EXPLAIN 的 key 列
执行带 USE INDEX 的语句时，不能靠“查询变快了”下结论。必须跑 EXPLAIN，盯住输出结果中 key 这一列的值。
- 如果
key显示为你指定的索引名（大小写、下划线必须完全一致），说明提示被识别且采纳； - 如果仍是
NULL或其他索引名，大概率是：索引名拼错、该索引不存在、字段存在隐式类型转换（比如varchar字段用数字比较）、MySQL 版本低于 5.7（部分云数据库默认禁用）； - 同时检查
rows值是否显著下降，以及Extra中是否还出现Using filesort或Using temporary——这两项消失才说明索引真正覆盖了排序/分组需求。
USE INDEX 是建议，不是命令，别指望它总听你的
USE INDEX 只是告诉优化器“优先考虑这几个索引”，它仍可能跳过你指定的索引，选一个它认为更优的路径。这在以下情况尤其明显：
- 指定索引的字段顺序与查询条件不匹配（比如索引是
(a,b)，但 WHERE 只有b = ?）； - 索引列存在大量 NULL 值或低选择性（如状态字段只有 3 个取值），优化器判断走索引反而比全表扫描慢；
- 表数据量极小（比如几百行），优化器直接放弃索引，因为一次 IO 就能读完所有数据页；
- 查询涉及函数或表达式（如
WHERE YEAR(created_at) = 2026），导致索引失效，USE INDEX也无力回天。
别跳过 ANALYZE TABLE，统计信息不准时 USE INDEX 很容易失效
优化器做决策依赖表的统计信息，包括索引基数（cardinality）。频繁增删改后，这些信息会滞后，导致即使写了 USE INDEX，优化器也可能因误判而拒绝使用。
执行 ANALYZE TABLE orders; 能强制更新统计信息，之后再跑 EXPLAIN，常能看到原本不生效的 USE INDEX 突然奏效了。
注意：这个操作会短暂锁表（InnoDB 是轻量级 MDL 锁），生产环境避开高峰期；阿里云 RDS 等托管服务可能限制该命令权限，需确认。
真正关键的不是“怎么写对”，而是“为什么没生效”。每次 USE INDEX 失败，都要回到 EXPLAIN + SHOW INDEX + ANALYZE TABLE 这三步闭环，漏掉任意一环都可能把问题归咎于语法，而实际是数据分布或统计偏差在捣鬼。
