隐式类型转换会引发全表扫描，导致UPDATE/DELETE语句锁住所有扫描行，在RC/RR下易演变为事实全表锁；需通过EXPLAIN SELECT + SHOW WARNINGS确认，关注type、key、rows及警告信息。
隐式类型转换本身不会直接导致“全表锁”，但它会引发全表扫描，而全表扫描在 UPDATE 或 DELETE 语句中会扩大加锁范围——最终表现为“锁住所有被扫描的行”，在 RC/RR 隔离级别下极易演变成事实上的全表锁（尤其当 WHERE 条件失效、type: ALL 时）。
看 EXPLAIN 的 type 和 key 是否已暴露问题
真正要盯的是 EXPLAIN SELECT 的输出，不是 UPDATE/DELETE 本身（MySQL 5.6.2+ 才支持 EXPLAIN UPDATE，且统计信息常不准）。只要看到以下任一现象，基本可断定是隐式转换在作祟：
-
type: ALL或type: index（非 const/ref），且key: NULL -
rows值等于或接近表总行数（哪怕只有几千行也一样） -
Extra中出现Using where（说明过滤下推失败，靠 Server 层硬扫）
注意：联合索引最左列若发生隐式转换（如 KEY idx_code_age (code, age)，但写成 WHERE code = 101），整个索引前缀失效，age 也无法利用。
执行 SHOW WARNINGS 确认隐式转换警告
EXPLAIN 只是线索，SHOW WARNINGS 才是铁证。在运行完 EXPLAIN SELECT ... 后立刻执行它，如果看到类似：
Warning | 1739 | Cannot use ref access on index 'idx_phone' due to type or collation conversion on field 'phone'
就说明 MySQL 明确拒绝使用该索引，原因就是类型或排序规则不一致。常见触发点包括：
-
VARCHAR字段传数字字面量（WHERE phone = 13800138000） -
INT字段传带空格/字母的字符串（WHERE id = ' 123 '或WHERE id = '123abc'） - JOIN 两边字段字符集不同（如一张表是
utf8mb4_unicode_ci，另一张是utf8mb4_general_ci）
查表结构和连接字段是否真正一致
别只看“都是 INT”或“都是 VARCHAR”，要逐项核对：
- 用
SHOW CREATE TABLE t1查字段定义，确认CHARSET和COLLATE完全一致 - 用
SELECT CHARSET(col), COLLATION(col) FROM t1 LIMIT 1查实际值的字符集与排序规则（可能受连接参数影响） - 检查符号性：
BIGINTvsBIGINT UNSIGNED不等价，JOIN 时会强制 CAST，索引失效 - 检查长度和精度：
DECIMAL(10,2)和DECIMAL(12,4)在比较时也可能触发转换
ORM 场景下尤其危险：MyBatis 的 #{userId} 若 Java 是 Long，但 DB 字段是 VARCHAR，SQL 日志里根本看不出引号缺失，只能靠 EXPLAIN + SHOW WARNINGS 反向验证。
UPDATE/DELETE 语句的锁范围必须按 SELECT 模拟验证
很多人误以为“我只更新 1 行，怎么会锁全表？”，但只要 WHERE 条件因隐式转换退化为全表扫描，InnoDB 就会对扫描到的每一行加 X 锁（RR 下还可能加间隙锁）。验证方式唯一可靠：
- 把原
UPDATE t SET x=1 WHERE y = 123改成SELECT * FROM t WHERE y = 123 - 确保没加函数、没用
${}拼接、没在列上套CAST() - 看
EXPLAIN的rows—— 如果是 100 万，那你的 UPDATE 就真在锁这 100 万行
最容易被忽略的是：即使最终只匹配出 1 行，只要扫描了 100 万行，这 100 万行就都处于加锁状态，其他事务更新任意一行都会被阻塞。
