force index 是优化器该用索引却未用时的硬性干预手段，必须紧贴表名后、where前，索引名需真实存在且匹配最左前缀，否则报错或失效。
FORCE INDEX 不是“让 MySQL 走索引”的开关，而是当优化器明明该用某个索引却没用时，你手动堵死错误路径的硬性干预手段——写错位置、索引名不匹配、或查询条件不满足最左前缀，它会直接报错或完全失效。
FORCE INDEX 必须紧贴表名后，位置错就等于没写
它不是独立语句，也不是注释式 hint，必须出现在 FROM table_name 之后、WHERE 之前，且括号不能省：
- ✅ 正确：
SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 - ❌ 错误：
SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_status)（语法不识别，报错或静默忽略） - ❌ 错误：
SELECT * FROM orders USE INDEX (idx_user_status) WHERE user_id = 123（这只是建议，优化器仍可选全表扫描） - 主键强制写法是
FORCE INDEX (PRIMARY)，注意大写PRIMARY，不是id或小写
索引名必须真实存在，且大小写敏感
MySQL 会校验索引是否存在，不匹配就中断执行，不是降级运行：
- 索引被重命名或删除后，所有含该
FORCE INDEX的 SQL 都会报ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy' - 索引名含特殊字符或为保留字（如
order_status_idx），必须用反引号：FORCE INDEX (`order_status_idx`) - 联合索引名要写全，比如实际叫
idx_user_id_status_created，就不能简写成idx_user_id -
FORCE INDEX (created_at)是非法的——created_at是列名，不是索引名
强制的前提是索引能覆盖查询条件，否则无效
它不会“修复”索引失效问题，只会拒绝无法使用的执行计划：
- 复合索引
(a, b, c)，但查询只写WHERE b = 1 AND c = 2→ 缺少最左列a，FORCE INDEX无意义，MySQL 直接退化为全表扫描或报错 - WHERE 中对索引列用了函数，如
WHERE YEAR(created_at) = 2024→ 即使强制idx_created_at，也无法使用，因为索引 B-tree 无法匹配函数结果 - 隐式类型转换：字段是
VARCHAR，但WHERE col = 123（传数字）→ 触发全表扫描，加FORCE INDEX也救不回来 - UPDATE/DELETE 中同样适用，但必须紧贴表名：
UPDATE logs FORCE INDEX (idx_device_id) SET status = 'done' WHERE device_id = 456
多表 JOIN 和分区表里容易踩坑
FORCE INDEX 只作用于单表，不会跨表传播，也不会自动约束分区范围：
- JOIN 查询中，每张表都要单独指定：
FROM t1 FORCE INDEX (i1) JOIN t2 FORCE INDEX (i2) ON t1.id = t2.ref_id - 分区表上，
FORCE INDEX不等于限定分区；若索引未建在分区键上，仍可能扫多个分区 - CTE 或子查询中，
FORCE INDEX在 MySQL 8.0+ 不生效，必须写在最外层主查询的表上 - JSON 字段即使建了虚拟列 + 索引，
FORCE INDEX也大概率被忽略——优化器对 JSON 路径的成本估算极不准
真正要用 FORCE INDEX 的时刻极少：EXPLAIN 明确显示 type=ALL 或 key=NULL，而你确认索引存在、字段匹配、无函数/转换，且刚跑过 ANALYZE TABLE 后优化器仍误判。它不是调优起点，而是排查终点——一旦加了，就得盯住索引生命周期和数据分布变化。
