force index是强制优化器使用指定索引的查询提示，必须紧接from后、索引名真实存在且大小写敏感、where满足最左前缀，否则报错或失效。

FORCE INDEX 语法和基本用法

MySQL 的 FORCE INDEX 是一种查询提示（hint），用于明确告诉优化器“必须使用某个索引”，即使它认为全表扫描更快。它不是万能开关，但能在优化器误判时快速干预。

• 必须写在 FROM 子句的表名后，紧跟 FORCE INDEX (index_name)
• 只对单表生效；多表 JOIN 中需对每张表单独指定
• 索引名是实际创建时的名字，不是列名，大小写敏感（取决于系统变量 lower_case_table_names）
• 如果指定的索引不存在或不适用于该查询条件（比如 WHERE 没覆盖索引前缀），MySQL 会报错 Unknown index 'xxx' for table 'yyy'

示例：

SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'paid' AND created_at > '2024-01-01';

FORCE INDEX 和 USE INDEX、IGNORE INDEX 的区别

三者都是索引提示，但行为差异关键：

• USE INDEX (a,b)：建议优化器“从这些索引里选一个”，仍可能退化为全表扫描
• FORCE INDEX (a)：强制走 a，若 a 无法支持查询条件（如无 WHERE 字段匹配），则直接报错或回退到全表扫描（取决于 MySQL 版本和 SQL_MODE）
• IGNORE INDEX (b)：明确排除 b，但不保证走哪个索引，只是缩小候选集

常见误操作：把 FORCE INDEX 当成“性能加速器”盲目加——如果索引本身区分度低（比如 status 只有 3 个值），强制走它反而更慢。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

什么时候该用 FORCE INDEX？

它不是日常优化手段，而是诊断和兜底工具：

• EXPLAIN 显示走了错误索引（比如走了 idx_user_id，但实际需要按时间范围筛选）
• 表数据分布突变（如某状态占比从 5% 涨到 95%），导致优化器统计信息滞后，选错执行计划
• 应用中存在固定模式的慢查询，且已确认某索引在该条件下一定更优（例如分页查询配合 created_at 覆盖索引）
• 临时绕过 bug：某些 MySQL 版本在 ORDER BY + LIMIT 场景下会忽略合适索引，FORCE INDEX 可稳定执行路径

注意：FORCE INDEX 不解决根本问题。长期依赖它，说明统计信息不准、索引设计不合理，或查询条件未对齐索引结构。

容易踩的坑和兼容性提醒

• MySQL 8.0+ 对 hint 语法更严格，FORCE INDEX 在 CTE 或子查询中不生效，必须放在最外层主表上
• 使用分区表时，FORCE INDEX 只作用于分区内的索引，不能跨分区强制
• 如果强制的索引是唯一索引但 WHERE 条件为 IS NULL，部分版本会忽略提示并走全表扫描
• 复合索引顺序很重要：强制 FORCE INDEX (idx_a_b_c)，但 WHERE 只有 WHERE c = ?，MySQL 无法使用该索引（最左前缀不匹配），此时提示无效甚至报错
• 不要把它写进 ORM 的通用查询模板里——ORM 很难安全拼接 hint，且不同环境索引名可能不一致

真正要稳住执行计划，优先更新统计信息（ANALYZE TABLE）、检查索引覆盖度、拆分大查询，而不是靠 FORCE INDEX 扛着走。它像手术刀，不是创可贴。