FORCE INDEX 必须紧贴表名后、WHERE前，位置错误则静默失效；仅在优化器本该用某索引却未选时生效，若索引不满足最左前缀、含函数、类型不匹配或已不存在，则强制无效或报错。
FORCE INDEX 位置写错就等于没写
MySQL 把 FORCE INDEX 当作 FROM 子句的语法组成部分，必须紧贴在表名（或别名）之后、WHERE 或 JOIN 之前。写错位置不会报错，但完全静默失效：
-
SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id = 123✅ 正确 -
SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_id)❌ 语法不识别，当普通文本忽略 -
SELECT * FROM orders JOIN logs FORCE INDEX (idx_ts) ON ...❌ 必须写在logs后、ON前，即JOIN logs FORCE INDEX (idx_ts) ON
UPDATE/DELETE 同理：UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123 是唯一合法写法；UPDATE orders SET ... WHERE ... FORCE INDEX () 会被彻底忽略。
索引本身不满足查询条件，FORCE 也无能为力
FORCE INDEX 不是“让 MySQL 用索引”的开关，而是“强制它从可用索引中选我指定的那个”。如果指定索引根本无法支撑当前 WHERE 条件，MySQL 会直接退化为全表扫描，甚至报错：
- 联合索引
idx_a_b_c(a,b,c)，但查询只写WHERE b = 1 AND c = 2→ 缺失最左列a，不满足最左前缀，强制无效 -
WHERE YEAR(created_at) = 2024→ 对索引列用函数，B+树里存的是完整时间戳，不是年份，索引无法参与比较 -
user_id是BIGINT，但写成WHERE user_id = '123'→ 隐式转换触发全表扫描，FORCE拦不住 - 索引名拼错，或该索引已被
DROP→ 直接报错：ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy'
优化器已选中该索引，FORCE 就不触发
如果 EXPLAIN 显示 key 字段已是你要的索引名，说明优化器本来就没选错——FORCE INDEX 在这种情况下完全不生效，也不报错，只是被跳过。它只在优化器本该用却没用时起作用，比如：
-
EXPLAIN显示type = ALL或key = NULL，但你知道存在匹配的索引（如WHERE created_at > '2025-01-01'，表上有idx_created_at） - 统计信息过期（
ANALYZE TABLE没跑过），优化器低估了索引价值 - 数据严重倾斜（某
status值占 98%），优化器误判回表成本高于顺序扫描
此时加 FORCE INDEX 才可能扭转执行路径；否则就是多余操作。
多表 JOIN 中漏掉任意一张表，就会失效
FORCE INDEX 只作用于单个表，不会跨表推导。多表 JOIN 时，每个表都必须显式声明自己的提示：
-
SELECT u.name, o.total FROM users u FORCE INDEX (PRIMARY) JOIN orders o FORCE INDEX (idx_user_id) ON o.user_id = u.id✅ -
SELECT u.name, o.total FROM users u JOIN orders o FORCE INDEX (idx_user_id) ON o.user_id = u.id❌users表没加提示，可能走错索引或全扫
注意：提示必须紧贴表名或别名后，不能放在 JOIN 关键字之后，也不能塞进 ON 条件里。分区表、JSON 字段、全文索引等特殊场景下，FORCE INDEX 的行为更不可靠，往往需要配合 PARTITION 或生成列等手段才能真正生效。
