FORCE INDEX 必须紧贴表名后、WHERE前，位置错误则完全失效；索引名须真实存在且匹配最左前缀，否则报错或退化全表扫描；仅对单表生效，UPDATE/DELETE及JOIN中需逐表指定。
FORCE INDEX 语法必须紧贴表名后，位置错就完全失效
它不是独立语句，也不是注释式提示，写错位置 MySQL 直接忽略——比如塞到 WHERE 后面、或当成子句末尾附加项，都不会起作用。
-
SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id = 123✅ 正确：FORCE INDEX紧跟在表名orders后 -
SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_id)❌ 无效：优化器当它是垃圾字符，执行计划不变 -
SELECT * FROM orders USE INDEX (idx_user_id) FORCE INDEX (idx_status)❌ 语法错误：二者不能共存 - 主键强制必须写
PRIMARY（全大写），不能写id或pk；前缀索引强制时也必须用完整索引名，不能简写列名
加了 FORCE INDEX 却没走索引？大概率是索引本身不匹配查询条件
FORCE 不是魔法开关，它只在“索引能用但优化器没选”时才生效。如果索引根本覆盖不了 WHERE 条件，MySQL 会直接退化为全表扫描，甚至报错。
- 复合索引
idx_a_b_c(a,b,c)，但查询写成WHERE b = 1 AND c = 2→ 缺少最左列a，强制也无效 - 查询值类型和索引列类型不一致，如
user_id BIGINT却写WHERE user_id = '123'→ 触发隐式转换，索引失效，强制无意义 - WHERE 中用了函数：
WHERE DATE(created_at) = '2025-06-01'→ 即使强制created_at上的索引，也无法使用 - 索引名拼错或已被删：直接报错
ERROR 1176 (HY000): Key 'idx_user' doesn't exist in table 'orders'
UPDATE/DELETE 里用 FORCE INDEX 更危险，容易放大锁和回表代价
SELECT 强制顶多慢点，UPDATE/DELETE 强制可能卡住整个事务链路，尤其在非覆盖索引场景下。
- 正确写法：
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'shipped' WHERE user_id = 123 - 错误写法：
UPDATE orders SET status = 'shipped' WHERE user_id = 123 FORCE INDEX (idx_user_id)→ 语法合法但无效果 - 若
idx_user_id不包含status字段，UPDATE 会先通过索引定位行，再回表读取旧值做判断，再更新二级索引+undo log，I/O 和锁范围都变大 - 线上执行前必须用
EXPLAIN FORMAT=TRADITIONAL模拟等价 SELECT，再结合SHOW PROFILE或慢日志观察实际耗时，不能只看 EXPLAIN 的 rows
JOIN 场景下 FORCE INDEX 必须逐表指定，且不跨表生效
优化器对每张表单独做索引选择，FORCE 只作用于紧邻它的那张表，不会传导或联动。
- 正确写法：
SELECT * FROM t1 FORCE INDEX (idx_a) JOIN t2 FORCE INDEX (idx_b) ON t1.id = t2.ref_id - 错误假设：
JOIN t2 ON t1.id = t2.ref_id加了t1的 FORCE 就能影响t2→ 完全无效 - 子查询中不支持 FORCE INDEX（MySQL 8.0.33 及之前所有版本）；视图定义里也不能写，会被忽略
- FORCE 是硬约束，一旦生效，优化器连“该索引只用前缀”这种降级路径都不给——要么全用，要么报错或退化
真正生效的前提，是你已经确认这个索引能覆盖查询的等值条件列、类型一致、没被函数污染，并且优化器确实误判了。它不是调优起点，而是验证终点。
