FORCE INDEX 仅在优化器本该用却未选某索引时生效；若执行计划未走指定索引，多因索引不满足查询条件（如字段缺失、类型不匹配、函数导致失效等）；UPDATE/DELETE中必须紧贴表名后使用，否则无效。
FORCE INDEX 不是“加了就快”的开关，它只在优化器本该用却没用某个索引时才起作用；如果执行计划里压根没走你指定的索引，大概率是索引本身不满足查询条件（比如 WHERE 字段不在索引列中、类型不匹配、或用了函数导致失效），而不是提示没生效。
FORCE INDEX 什么时候真正生效
它只对优化器原本**不打算选**的那个索引起约束作用：当 EXPLAIN 显示走了全表扫描、或用了别的索引，而你确认目标索引能覆盖 WHERE / ORDER BY / GROUP BY 字段时，FORCE 才可能扭转执行计划。
- 优化器已经选中该索引 → FORCE INDEX 完全不触发，也不报错
- 索引名拼错或已被删除 → 直接报错
ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy' - 索引存在但无法用于当前查询（如
WHERE YEAR(created_at) = 2024）→ 强制也无效，执行计划不变 - 复合索引顺序不匹配（如索引是
(a, b)，但查询只用WHERE b = 1）→ 即使 FORCE，也无法使用
UPDATE 和 DELETE 里 FORCE INDEX 的写法陷阱
很多人在 UPDATE 中写成 UPDATE table_name SET ... WHERE ... FORCE INDEX (idx)，这是错的——FORCE 必须紧贴表名后，否则被忽略。
- 正确写法：
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123 - 错误写法：
UPDATE orders SET ... WHERE user_id = 123 FORCE INDEX (idx_user_id)（语法上不报错，但无效果） - DELETE 同理：
DELETE FROM logs FORCE INDEX (idx_time) WHERE created_at - JOIN 场景下，每个表都要单独加：
SELECT * FROM t1 FORCE INDEX (idx_a) JOIN t2 FORCE INDEX (idx_b) ON t1.id = t2.ref_id
FORCE INDEX 和 USE INDEX 的关键区别
别把它们当同义词混用。USE INDEX 是轻量建议，FORCE INDEX 是强约束，语义和行为完全不同。
-
USE INDEX (idx)：告诉优化器“只允许从这几个索引里选”，但它仍可选全表扫描 -
FORCE INDEX (idx)：意思是“必须用这个索引，否则宁可报Impossible WHERE” -
IGNORE INDEX (idx)：只排除某个索引，不指定替代方案 - 三者都只影响单个表，多表 JOIN 时需分别指定
为什么线上环境要慎用 FORCE INDEX
它把索引选择权从优化器手里硬抢过来，短期见效快，长期隐患大。
- 数据分布变化后（比如某字段值倾斜加剧），原来最优的索引可能变最差，但 FORCE 还在硬绑
- 索引重命名或重建后，SQL 会直接失败，且错误往往在低峰期测试不到
- 在分区表或 NDB 引擎上，部分 MySQL 版本会静默忽略 FORCE，导致行为不一致
- 真正该做的是更新统计信息：
ANALYZE TABLE table_name，或检查隐式类型转换（如WHERE id = '123'对 int 字段）
最常被忽略的一点：FORCE INDEX 解决不了索引设计缺陷。如果 WHERE 条件涉及多个字段却只有单列索引，或者排序字段不在复合索引后缀位置，加再多 FORCE 也没用——这时候该改索引，不是改 SQL。
