force index 是强制 mysql 使用指定索引的硬性干预手段，必须紧贴表名后、where 前，索引名须真实存在且匹配最左前缀原则，否则报错或失效。
FORCE INDEX 不是“让 MySQL 走索引”的万能开关，而是当优化器明明该用某个索引却没用时，你手动堵死错误路径的硬性干预手段——写错位置、索引名不匹配、或查询条件不满足最左前缀，它会直接报错或完全失效。
FORCE INDEX 必须紧贴表名后、WHERE 前
它不是独立语句，也不是注释式 hint，MySQL 只在 FROM table_name 之后、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)（优化器当垃圾字符忽略） - ❌ 语法错误：
SELECT * FROM orders USE INDEX (idx_user_id) FORCE INDEX (idx_status)（二者不能共存） - 括号不能省，
FORCE INDEX idx_user_id是非法语法
索引名必须真实存在且大小写敏感
MySQL 会校验索引是否存在，不匹配就中断执行，不是降级运行。
- 主键强制必须写
FORCE INDEX (PRIMARY)，注意全大写PRIMARY，不能写id或pk - 索引名含特殊字符或为保留字（如
order_status_idx），必须用反引号：FORCE INDEX (`order_status_idx`) - 联合索引名要写全，比如实际叫
idx_user_id_status_created，就不能简写成idx_user_id - 报错示例：
ERROR 1176 (HY000): Key 'idx_user' doesn't exist in table 'orders'—— 索引被删或重命名后，所有含该 FORCE INDEX 的 SQL 都会崩
强制的前提是索引能覆盖查询条件
它不会“修复”索引失效问题，只会拒绝无法使用的执行计划。加了却没走索引？大概率是索引本身不匹配 WHERE 条件。
- 复合索引
idx_a_b_c(a,b,c)，但查询写成WHERE b = 1 AND c = 2→ 缺少最左列a，强制也无效 - WHERE 中用了函数：
WHERE DATE(created_at) = '2025-06-01'→ 即使强制created_at上的索引，也无法使用 - 隐式类型转换：
user_id BIGINT却写WHERE user_id = '123'→ 触发转换，索引失效，强制无意义 -
FORCE INDEX (created_at)是非法的 ——created_at是列名，不是索引名
UPDATE/DELETE 和 JOIN 场景下更危险
SELECT 强制顶多慢点，UPDATE/DELETE 强制可能卡住整个事务链路，尤其在非覆盖索引场景下。
- UPDATE 强制了非覆盖索引，会先通过索引定位行，再回表读旧值做判断，再更新二级索引 + undo log，I/O 和锁范围都变大
- JOIN 中 FORCE INDEX 必须逐表指定，且不跨表生效：
SELECT * FROM t1 FORCE INDEX (idx_a) JOIN t2 FORCE INDEX (idx_b) ON t1.id = t2.ref_id - 没有
EXPLAIN UPDATE，只能用EXPLAIN FORMAT=TRADITIONAL模拟等价 SELECT，再结合SHOW PROFILE或慢日志观察实际耗时 - 线上执行前必须在从库或影子表上压测，不能只看 EXPLAIN 的
rows
真正难的从来不是写对那行 FORCE INDEX，而是确认“这个索引确实能用”“优化器这次真选错了”“WHERE 条件没偷偷触发隐式转换”。这些细节藏在执行计划和数据类型里，不在语法书上。
