force index不是强制走索引的开关，而是当优化器该用却未用某索引时的硬性干预手段；其语法必须紧贴from后、括号内填真实索引名，且索引需满足最左前缀等条件，否则报错或失效。
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 ... - 如果用了表别名，hint 必须紧贴别名后：
FROM users u FORCE INDEX (idx_users_id) JOIN orders o FORCE INDEX (idx_orders_user_id) ON ... - 分区表上，
FORCE INDEX不会限制扫描分区范围，仍可能扫多个分区；需配合PARTITION (p2024)显式指定 - 从 MySQL 8.0 开始，
FORCE INDEX在 CTE 或子查询中不生效，必须写在最外层主查询的表上
真正关键的不是“怎么写对”，而是“为什么非得绕过优化器”——它绕过了成本估算，一旦数据分布突变（比如某状态值占比从 1% 涨到 90%），原本高效的索引可能变成性能黑洞，而且这种问题不会报错，只会变慢。
