force index是强制mysql使用指定索引的硬性指令，必须紧接from后、索引真实存在且能覆盖where最左前缀字段，否则报错或退化；不支持函数操作、大小写敏感、多索引名等错误写法。
FORCE INDEX 是最直接有效的手段，但必须写对位置、选对索引、避开函数陷阱，否则它不会生效，甚至报错。
FORCE INDEX 的语法和生效前提
它不是可选提示，而是带校验的强制指令：MySQL 会检查指定索引是否能覆盖 WHERE 条件中的至少一个字段。不满足就直接报错，比如 ERROR 1176 (HY000): Key 'idx_created_at' doesn't exist in table 'logs'——注意，这不一定代表索引真不存在，更可能是大小写不匹配（InnoDB 索引名区分大小写），或该索引建在 MyISAM 表上而当前引擎是 InnoDB（部分老迁移环境会踩这个坑）。
正确写法只有一种：SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 AND status = 'paid'。常见错误包括：
- 把
FORCE INDEX写在WHERE后面或JOIN子句里 - 括号里写了多个索引名，如
FORCE INDEX (a, b)（语法错误，只支持单个） - 索引名用了反引号或引号包裹，如
FORCE INDEX (`idx_name`)（会解析失败）
USE INDEX 和 /*+ INDEX() */ 的实际差异
USE INDEX (idx_name) 是软提示，优化器仍可能无视它去用主键或全表扫描；而 /*+ INDEX(orders idx_user_status) */ 是 MySQL 8.0+ 的新式 Optimizer Hint，语义更明确，且支持多表场景下的精细控制，例如在 JOIN 中单独约束某一张表的索引选择。
但要注意：这种注释式写法必须紧贴 SELECT 关键字后，不能换行，也不能加空格干扰解析。示例：
SELECT /*+ INDEX(orders idx_user_status) */ * FROM orders WHERE user_id = 123 AND status = 'paid';
如果同时用了 FORCE INDEX 和 /*+ INDEX() */，前者优先级更高，后者会被忽略。
为什么 EXPLAIN 显示 key 是预期索引，但 rows 却高得离谱？
这通常意味着索引“被用了”，但没被“有效用”——比如查询条件对索引字段做了函数操作：WHERE YEAR(create_time) = 2024，此时哪怕加了 FORCE INDEX (idx_create_time)，MySQL 也退化为全表扫描，EXPLAIN 的 key 字段仍显示索引名，但 rows 和 Extra 里会出现 Using where; Using index 以外的冗余动作。
真正要验证是否命中索引前缀，得看 EXPLAIN 的 key_len 值是否符合预期长度，并确认 WHERE 条件是否严格遵循最左前缀原则。例如复合索引 idx_user_id_status 是 (user_id, status)，那么 WHERE status = 'paid' 单独出现时，FORCE INDEX 也救不了——它根本无法跳过第一个字段做范围扫描。
UPDATE/DELETE 语句也能用 FORCE INDEX，但有隐藏风险
可以，语法一致：UPDATE orders FORCE INDEX (idx_user_id) SET status = 'shipped' WHERE user_id = 123。但这里容易被忽略的是锁范围：如果强制使用的索引区分度低（比如大量 user_id = 0），会导致锁住远超预期的行数，加剧并发冲突。生产环境改写这类语句前，务必用 SELECT ... FOR UPDATE 模拟执行，观察 EXPLAIN FORMAT=JSON 中的 used_range_access 和 rows_examined_per_scan 指标。
另外，分区表上使用 FORCE INDEX 时，若索引未包含分区键，MySQL 可能拒绝执行并报错，这点文档极少提及，但实测在 8.0.33+ 版本中已稳定复现。
