force index 是唯一真正强制 mysql 使用指定索引的语法，仅在索引能用但优化器未选时生效；必须紧贴表名后、where前，索引名真实存在且满足最左前缀，否则报错或失效。
FORCE INDEX 是唯一真正强制 MySQL 执行器使用指定索引的语法，但它只在“索引能用但优化器没选”时生效；写错位置、索引不匹配或类型不一致，它就完全失效甚至报错。
FORCE INDEX 必须紧贴表名后，位置错就等于没写
MySQL 解析 FORCE INDEX 时只认一种位置：FROM table_name FORCE INDEX (index_name)。它不是注释，也不是独立子句，塞到 WHERE 后、JOIN 条件里、或者 UPDATE 的 SET 后面，都会被忽略。
-
SELECT * FROM orders FORCE INDEX (idx_user_id) WHERE user_id = 123✅ 正确 -
SELECT * FROM orders WHERE user_id = 123 FORCE INDEX (idx_user_id)❌ 无效，优化器当垃圾字符处理 -
UPDATE orders SET status = 'done' WHERE user_id = 123 FORCE INDEX (idx_user_id)❌ 语法合法但无效果 -
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123✅ 正确
索引必须真实存在且能覆盖最左前缀条件
FORCE INDEX 不是绕过规则的魔法开关。它会校验索引是否存在、是否能用于当前 WHERE 条件——不满足就直接报错或退化为全表扫描。
- 索引名大小写敏感：
idx_user_id和IDX_USER_ID在 InnoDB 中是不同索引 - 主键索引必须写成
PRIMARY，不能写id或pk - 复合索引
idx_a_b_c(a,b,c)，查询WHERE b = 1 AND c = 2→ 缺少最左列a，强制也无效 -
WHERE DATE(created_at) = '2025-09-01'→ 函数导致索引失效，FORCE INDEX (idx_created_at)白加 - 字段类型不一致：
user_id BIGINT却写WHERE user_id = '123'→ 隐式转换，索引不可用
UPDATE/DELETE 和 JOIN 场景下容易踩坑
FORCE INDEX 在非 SELECT 场景中风险更高：它可能放大锁范围、触发额外回表、甚至卡住事务链路。
- UPDATE 强制非覆盖索引时，MySQL 先通过索引定位行，再回表读旧值做判断，I/O 和锁开销都变大
- JOIN 中每个表都要单独加：
SELECT * FROM t1 FORCE INDEX (idx_a) JOIN t2 FORCE INDEX (idx_b) ON t1.id = t2.ref_id—— 少一个就只对那张表生效 - 线上执行前必须用等价
SELECT+EXPLAIN FORMAT=TRADITIONAL模拟，再结合SHOW PROFILE看实际耗时，不能只信 EXPLAIN 的rows - 分区表场景下，FORCE INDEX 不限制分区裁剪，可能扫多个分区，即使单个分区内是覆盖的，整体仍显示
Using where
别和 USE INDEX 或 /*+ INDEX() */ 混用
三者语义和优先级完全不同，混用会导致行为不可控。
-
USE INDEX (idx_name)是软提示，优化器可无视；FORCE INDEX (idx_name)是硬约束，不满足就报错或退化 - MySQL 8.0+ 的注释式提示
/*+ INDEX(t1 idx_name) */必须紧贴SELECT关键字后，不能换行，也不能有空格干扰解析 - 如果同时写了
FORCE INDEX和/*+ INDEX() */，前者优先级更高，后者被忽略 -
USE INDEX和FORCE INDEX不能共存：USE INDEX (a) FORCE INDEX (b)直接语法错误
真正要验证 FORCE INDEX 是否起效，得看 EXPLAIN 的 key_len 是否符合预期长度，并确认 Extra 里有没有 Using index（覆盖）或 Using where（回表）。光看 key 字段显示索引名，不代表它被有效用了。
