Force INDEX失效时锁全表，是因为WHERE条件本身导致索引无法定位行（如隐式转换、函数运算、左模糊等），InnoDB被迫全表扫描，进而升级为表级锁；真正应优先修复查询写法而非依赖强制。
Force Index 失效时为什么锁全表
因为 FORCE INDEX 只影响优化器选择哪个索引，不改变 WHERE 条件是否能走索引；一旦条件本身导致索引失效（比如隐式类型转换、函数运算），InnoDB 就无法定位具体行，只能退化为全表扫描 + 全表加锁。
哪些“强制”其实没用
常见误以为加了 FORCE INDEX 就万事大吉，但以下情况它完全不起作用：
-
WHERE user_id = 12345——user_id是VARCHAR，传整数触发隐式转换，索引列被函数化，FORCE INDEX被忽略 -
WHERE DATE(created_at) = '2025-06-01'—— 对索引列用函数，B+树键值无法直接匹配，优化器直接弃用索引，强制也无效 -
WHERE name LIKE '%abc'—— 左模糊不满足前缀匹配，索引结构无法支持，FORCE INDEX不会强行“硬用”，而是报错或退为 ALL -
WHERE status != 'deleted'—— 低选择性 + 排除语义，优化器估算回表成本过高，即使强制也会被忽略
行锁变表锁的临界点在哪
InnoDB 行锁的前提是：WHERE 条件能通过索引**精确定位到某几行**。只要执行计划里出现 type: ALL 或 key: NULL，就说明没走索引 —— 此时 UPDATE/DELETE 会升级为表级意向锁（IX），再配合全表扫描，实际效果等同于锁住所有行。
验证方式很简单：
- 执行
EXPLAIN FORMAT=JSON查看"access_type"是否为"ALL" - 查
INFORMATION_SCHEMA.INNODB_TRX，看trx_mysql_thread_id对应的事务是否持有TABLE LOCK而非RECORD LOCK - 在另一个会话执行
SELECT * FROM employee WHERE name = '1002' FOR UPDATE，如果被阻塞，说明前一个事务已锁全表
真正该做的不是加 FORCE，而是先让索引可被使用
强制索引是“最后一搏”，不是兜底方案。容易被忽略的关键点是：索引是否生效，90% 取决于查询写法本身，而不是优化器选不选。
修复优先级建议：
- 检查
EXPLAIN的key和type字段，确认是否真走了索引 - 比对列定义类型和参数类型，
VARCHAR就必须传字符串，INT就不能拼接'123' - 把
DATE(col)改成col >= '2025-06-01' AND col - 左模糊搜索不要硬扛，要么改业务逻辑（如前端限制输入位置），要么换
FULLTEXT或 ES
很多人调完 FORCE INDEX 发现还是慢、还是锁表，问题从来不在“要不要强制”，而在于“能不能用”。
