force index 仅在优化器本该用某索引却未选时有效；若执行计划未走指定索引，多因索引不满足条件（如缺失最左前缀、隐式转换、函数操作等），而非提示失效；语法必须紧贴表名后、where前，位置错误则静默无效。
FORCE INDEX 不是“加了就快”的开关，它只在优化器本该用某个索引却没选时才起作用；如果执行计划里压根没走你指定的索引，大概率是索引本身不满足查询条件，而不是提示没生效。
FORCE INDEX 必须紧贴表名后写，位置错就等于没写
MySQL 把 FORCE INDEX 当作 FROM 子句的一部分，语法上必须紧跟在表名（或别名）之后、WHERE 之前。写错位置不会报错，但完全无效。
-
SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id = 123✅ 生效 -
SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_id)❌ 语法错误，MySQL 直接报错 -
SELECT * FROM orders USE INDEX (idx_user_id) WHERE user_id = 123⚠️ 仅建议，优化器仍可忽略
UPDATE 和 DELETE 同理：UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123 是唯一正确写法；UPDATE orders SET ... WHERE ... FORCE INDEX (...) 这种写法会被静默忽略。
强制不了？先查查索引能不能用上
加了 FORCE INDEX 却还是全表扫描（type=ALL），常见原因不是语法问题，而是索引根本覆盖不了当前查询条件。
- 复合索引
idx_a_b_c(a,b,c)，但查询只写WHERE b = 1→ 缺少最左列a，即使强制也无效 - 字段类型不匹配，比如
user_id是BIGINT，但写成WHERE user_id = '123'→ 隐式转换导致索引失效 - 对索引列用了函数，如
WHERE YEAR(created_at) = 2024→ 索引无法用于范围判断，强制无意义 - 索引名拼错，或该索引已被
DROP→ 查询直接报错：ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy'
JOIN 场景下每个表都要单独加，不能省
多表 JOIN 时，FORCE INDEX 只影响单个表，优化器不会跨表推导。漏掉任意一个表，那个表就可能退化为全表扫描或误选索引。
-
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表没加提示，可能走错索引或全扫
注意：hint 必须紧贴表名或别名后，不能放在 JOIN 关键字之后，也不能写在 ON 条件里。
FORCE vs USE：语义不同，风险差很多
别把 USE INDEX 和 FORCE INDEX 当成一回事。前者是轻量建议，后者是硬性接管——它绕过优化器的成本估算，哪怕实际更慢也必须走。
-
USE INDEX (idx_a)：告诉优化器“只考虑这个索引”，但它仍可选全表扫描 -
FORCE INDEX (idx_a)：意思是“必须用这个索引，否则宁可报Impossible WHERE” -
IGNORE INDEX (idx_b)：只排除某个索引，不指定替代方案
线上环境用 FORCE INDEX 前，得确认三件事：索引真实存在、查询条件匹配最左前缀、数据分布没发生剧烈倾斜（比如某 status 值占比突然超 95%）。一旦忽略这些，它带来的不是提速，而是隐蔽的性能黑洞。
