隐式字段转换本身不会直接锁表，但会导致索引失效→优化器选低效路径→查询变慢、事务持锁时间延长→间接加剧锁竞争甚至触发MDL等待。
隐式字段转换本身不会直接锁表，但它会引发索引失效 → 连接顺序错乱 → 优化器被迫选低效执行路径 → 查询变慢、事务持锁时间拉长 → 间接加剧锁竞争甚至触发MDL等待
为什么 t1.a = t2.a 会丢掉索引
当 t1.a 是 INT、t2.a 是 CHAR(20)（或 VARCHAR），MySQL 必须对其中一列做隐式转换才能比较。通常规则是：字符串转数字（调用 CONVERT() 或 CAST()）——这意味着 t2.a 上的索引无法用于范围查找或等值匹配。
- 即使
t2.a有索引，WHERE t2.a = 123也会全表扫描，因为实际执行的是WHERE CAST(t2.a AS SIGNED) = 123 - 连表时若
t2变成驱动表，而它又因转换无法走索引，就会扫全表去匹配t1，大幅延长事务持有行锁/表锁的时间 - 更隐蔽的是：如果
t2.a是utf8mb4而t1.a是latin1，还会触发字符集隐式转换，同样使索引失效
如何快速定位隐式转换问题
别靠猜。在慢查询的 EXPLAIN 输出里盯住 type 和 Extra 列：
-
type: ALL或type: index（而非ref/eq_ref）且连接条件涉及两表字段 → 高概率类型不匹配 -
Extra出现Using where; Using join buffer或Impossible WHERE（因转换后值溢出）→ 字符集或数值范围冲突 - 用
SHOW WARNINGS看优化器重写后的 SQL，找cast(... as ...)或convert(... using ...)
统一字段类型与字符集的实操要点
改表结构是根治方式，但生产环境必须控制风险：
- 优先改「被驱动表」字段：比如
t2.a是被驱动方，就把它从VARCHAR(20)改成INT UNSIGNED（注意校验存量数据是否可转） - 字符集必须显式指定：ALTER TABLE 时加
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，不能只依赖库级默认值 - 避免跨字符集 ALTER：如从
utf8直接转utf8mb4，可能因长度超限失败；先MODIFY COLUMN a VARCHAR(255) CHARACTER SET utf8mb4，再改 collation - 使用
ALGORITHM=INPLACE, LOCK=NONE（仅限支持 Online DDL 的版本和操作），否则 DDL 本身就会锁表
上线前必须验证的三件事
改完不等于安全，尤其在分库分表或读写分离架构下：
- 确认所有应用代码里的参数绑定类型一致：Java 用
setInt()而非setString()传数字型字段 - 检查中间件（如 ShardingSphere、MyCat）是否对字段类型做了透传，某些代理层会强制把数字转字符串再发给 MySQL
- 在从库上跑一遍
EXPLAIN FORMAT=JSON，确认执行计划和主库一致 —— 字符集不一致时，从库可能因 server 层配置不同导致转换行为差异
最易被忽略的是：隐式转换引发的问题往往在流量高峰才暴露，因为此时慢查询放大了锁等待链。不要只盯着 DDL 是否成功，要盯住变更后第一条真实业务请求的执行计划和锁等待时间。
