FORCE INDEX 是优化器本该用却未选某索引时的临时干预手段，仅在 EXPLAIN 显示 type=ALL 或 key=NULL 且 WHERE 条件明显匹配已有索引时才可能生效；必须紧贴表名后、WHERE 前，位置错误则静默失效。
FORCE INDEX 不是“让 MySQL 用索引”的开关，而是当优化器本该选某个索引却没选时的临时干预手段；它只在 EXPLAIN 显示 type = ALL 或 key = NULL，但 WHERE 条件明显匹配已有索引时才可能起效。
FORCE INDEX 位置写错就等于没写
MySQL 把 FORCE INDEX 当作 FROM 子句的语法组成部分，必须紧贴表名（或别名）之后、WHERE 或 JOIN 之前。写错位置不会报错，但完全静默失效：
-
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 JOIN logs FORCE INDEX (idx_ts) ON ...❌ 必须写成JOIN logs FORCE INDEX (idx_ts) ON -
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123✅ 唯一合法写法
加了 FORCE INDEX 却没走索引？问题大概率不在提示本身
强制失败通常不是语法问题，而是索引无法支撑查询条件。MySQL 不会“强行用一个不能用的索引”，它会直接退化为全表扫描或报错：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 联合索引
idx_a_b_c(a,b,c)，但查询只写WHERE b = 1 AND c = 2→ 缺失最左列a，不满足最左前缀，强制无效 -
WHERE YEAR(created_at) = 2024→ 对索引列用函数，B+树里存的是完整时间戳，索引无法参与比较 -
user_id是BIGINT，但写成WHERE user_id = '123'→ 隐式转换触发全表扫描，FORCE拦不住 - 索引名拼错，或该索引已被
DROP→ 直接报错：ERROR 1176 (HY000): Key 'xxx' doesn't exist in table 'yyy'
EXPLAIN 已显示用了你要的索引，FORCE 就不会触发
FORCE INDEX 只在优化器“本该用却没用”时起作用。如果 EXPLAIN 的 key 字段已是你要的索引名，说明优化器本来就没选错——FORCE INDEX 在这种情况下完全不生效，也不报错，只是被跳过。
真正需要它的典型场景包括：
-
EXPLAIN显示type = ALL或key = NULL，但你知道存在匹配索引（如WHERE created_at > '2025-01-01'，而表上有idx_created_at） - 统计信息过期（
ANALYZE TABLE没跑过），优化器低估了索引价值 - 数据严重倾斜（某
status值占 98%），优化器误判回表成本高于顺序扫描 - MySQL 旧版本对
ORDER BY ... LIMIT的代价估算 bug（如 5.7 某些 patch 版本）
最危险的不是加了 FORCE INDEX 没效果，而是它掩盖了统计不准这个安静的问题：没有日志、不报错、不告警，直到慢查询像雪崩一样涌进来。
