force index 仅在优化器本不选你指定索引但该索引实际更优时才起作用，需满足索引能用于where/order by/group by，且写法正确、索引存在且匹配查询条件。
FORCE INDEX 什么时候才真正起作用
MySQL 的 FORCE INDEX 不是“一加就快”，它只在优化器原本**不选你想要的索引**、但你确信那个索引更优时才需要。比如 EXPLAIN 显示走了全表扫描或用了错误的索引，而你知道某复合索引能覆盖查询条件和排序字段。
- 常见错误现象：
FORCE INDEX加了但执行计划没变——说明该索引根本不符合查询条件（如 WHERE 字段不在索引列中，或类型不匹配导致无法使用） - 只有当索引能用于
WHERE、ORDER BY或GROUP BY时，FORCE INDEX才可能被采纳 - 如果强制的索引是单列索引，而查询条件涉及多列且顺序不一致，MySQL 仍可能拒绝使用（例如索引是
(a)，但 WHERE 是b = ? AND a = ?）
FORCE INDEX 的写法和位置不能错
它必须紧贴在 FROM 子句的表名之后，不能放在 JOIN 条件里，也不能跨表混用。
- 正确写法：
SELECT * FROM t1 FORCE INDEX (idx_name) WHERE ... - 错误写法：
SELECT * FROM t1 WHERE ... FORCE INDEX (idx_name)（语法报错） - 多表 JOIN 中，每个表要单独加：
FROM t1 FORCE INDEX (i1) JOIN t2 FORCE INDEX (i2) ON ... - 如果索引名写错、或该索引不存在，MySQL 不报错，但会退化为默认优化策略（容易误以为“生效了”）
比 FORCE INDEX 更安全的替代方案
多数情况下，FORCE INDEX 是临时止痛药；修好索引设计或统计信息往往更治本。
-
ANALYZE TABLE能更新表的统计信息，有时能让优化器自动选对索引，无需强制 - 用
USE INDEX替代FORCE INDEX：前者只是“建议”，后者是“硬性要求”，但 MySQL 在无法使用时会直接报错（如索引不可用），反而暴露问题 - 检查是否因隐式类型转换导致索引失效：比如字段是
VARCHAR，但 WHERE 里写了WHERE col = 123（数字），这时加FORCE INDEX也无效 - 小表或结果集极小时，优化器可能主动放弃索引走全表扫描——这是合理行为，强行索引反而更慢
FORCE INDEX 对执行计划和性能的真实影响
它不改变数据访问逻辑，只干预索引选择，但副作用明显。
- 可能导致
Using filesort或Using temporary消失（如果强制的索引恰好覆盖 ORDER BY） - 也可能引入回表放大：比如强制一个只含 WHERE 字段的索引，但 SELECT * 需要其他列，就会大量随机 IO
- 在分区表上使用时，
FORCE INDEX不会限制扫描分区范围，仍可能扫多个分区 - 从 MySQL 8.0 开始，
FORCE INDEX在 CTE 或子查询中不生效，必须写在最外层主查询的表上
强制索引这事，核心不是“怎么写对”，而是“为什么非得绕过优化器”。很多 case 其实是索引缺失、统计信息陈旧、或者查询写法触发了隐式转换——这些地方比死磕 FORCE INDEX 更值得花时间查。
