隐式转换导致索引失效，使行锁升级为间隙锁或临键锁，扩大锁范围引发死锁；根源在于字符集或类型不匹配触发convert()/cast()，破坏b+树有序性，迫使全表扫描并锁定大范围索引区间。
隐式转换让索引失效，锁从单行变成一片
MySQL 优化器在能走索引时，只对匹配的记录加行锁（Record Lock）；一旦因隐式转换导致索引失效，就会退化为全表扫描或范围扫描——InnoDB 不得不给所有扫描到的记录加锁，甚至升级为间隙锁（Gap Lock）或临键锁（Next-Key Lock）。比如 WHERE phone = 13800138000（phone 是 VARCHAR），MySQL 实际执行的是 CAST(phone AS SIGNED)，B+ 树无法利用有序性，只能逐行计算，锁住整段索引区间。
字符集不匹配触发 CONVERT()，锁范围失控
当查询字段与参数字符集不一致（如字段是 utf8mb4_0900_as_cs，而参数默认按 latin1 传入），MySQL 内部会插入 CONVERT(phone USING utf8mb4)。这个隐式转换函数无法下推到存储引擎，导致索引无法命中。EXPLAIN 中常见 type: ALL 或 Extra: Using where; Using index condition 却没走索引。此时事务锁住的不是目标行，而是整个 phone 索引的间隙，多个事务在相同大范围内加锁 + 加锁顺序不同 → 循环等待立刻成型。
为什么 SELECT FOR UPDATE + 隐式转换特别危险
业务常用 SELECT ... FOR UPDATE 做幂等校验，但若 WHERE 条件存在隐式转换，它就不是“锁一行”，而是“锁一段”。例如唯一键 resource_key 是 VARCHAR，却用数字查询：SELECT * FROM resource WHERE resource_key = 123 FOR UPDATE。InnoDB 会锁住 (122, 124) 这个间隙（Next-Key Lock），两个并发请求都试图插入 123，结果互相等待对方释放间隙锁 —— 死锁日志里反复出现 waiting for lock_mode X locks gap before rec insert intention 就是这个信号。
验证和修复的关键动作
不要只信 EXPLAIN，要交叉验证运行时行为：
- 开启死锁日志：
SET GLOBAL innodb_print_all_deadlocks = ON，观察日志中是否还有 gap 锁等待 - 查字段定义：
SHOW FULL COLUMNS FROM table_name LIKE 'col_name'，确认Collation是否统一 - 连接层强制指定：
characterEncoding=utf8mb4&collationServer=utf8mb4_0900_as_cs，避免 JDBC 默认用latin1 - ALTER 字段时别用
utf8mb4_general_ci，它宽松比较易弃索引；优先选utf8mb4_0900_as_cs
真正难的不是改配置，是让所有链路（应用、ORM、中间件、DBA脚本）对齐类型和字符集——漏掉一环，隐式转换就藏在某次拼接或某条日志里等着触发死锁。
