字符串字段与整型字段JOIN必然触发隐式转换，导致索引失效、全表扫描（EXPLAIN显示type=ALL、key=NULL）；根本解法是统一字段类型、字符集、COLLATION及NULL属性，而非使用CAST或应用层兜底。
字符串字段和整型字段 JOIN 时必然触发隐式转换，这不是“可能”，而是 MySQL（及多数主流数据库）的类型兼容性规则决定的——它必须把两边转成同一类型才能比较，而这个转换过程直接破坏索引结构。
MySQL 怎么处理 a.id = b.user_id（INT vs VARCHAR）
当 a.id 是 BIGINT、b.user_id 是 VARCHAR(20)，MySQL 默认把整列 b.user_id 逐行转为数字再比对。B+树索引依赖原始字符串的字典序，一旦转成数字，顺序完全不可预测，优化器只能放弃索引，走 type=ALL。
- 你看到
EXPLAIN中b表的key为NULL、rows等于全表行数，就是铁证 - 哪怕
b.user_id上建了索引，也完全不会被用到 - 这种转换不是“一次转换后复用”，而是每行都调用一次
strntoll()类函数，CPU 开销陡增
CAST 或 CONVERT 写在 ON 里为什么更糟
显式加 ON a.id = CAST(b.user_id AS SIGNED) 看似可控，实则坐实索引失效：函数作用于索引列，优化器无法下推查找条件到存储引擎层。
- 执行计划里必出
Filter: CAST(b.user_id AS SIGNED) = a.id，说明是逐行过滤，不是索引定位 -
CONVERT(' 123 ', SIGNED)会静默截空格，但遇到'abc123'就变成0，关联错乱 - PostgreSQL 加
::BIGINT同样无效，执行计划显示Filter: ((b.user_id)::bigint = a.id)
字符集或 COLLATION 不一致也会触发隐式转换
哪怕两边都是 VARCHAR(32)，只要 COLLATION 不同（比如 utf8mb4_0900_as_cs vs utf8mb4_unicode_ci），MySQL 就会悄悄做 CONVERT(b.name USING utf8mb4)，结果仍是 key=NULL。
- 验证命令：
SHOW FULL COLUMNS FROM b LIKE 'user_id'，重点比对Collation列 - 跨库 JOIN 尤其危险：两个库默认字符集不同，或一张表建于老版本（如
utf8），另一张是utf8mb4 - 临时用
ON a.name = b.name COLLATE utf8mb4_unicode_ci能跑通，但只是拿 CPU 换可用性，不解决性能
应用层传参不干净，改完表也白搭
就算你把 b.user_id 改成了 BIGINT NOT NULL，Java 里仍用 "WHERE id = '" + userId + "'" 拼 SQL，或者 MyBatis 写 #{userId} 却没配 jdbcType=INTEGER，MySQL 还是会把 "123" 当字符串处理，照样触发隐式转换。
- 正确做法：PreparedStatement 显式绑定类型，如
ps.setLong(1, userId)或 Python 的cursor.execute("... WHERE id = %s", (123,)) - API 入口层必须校验：拒绝
"123.0"、" 123 "、"U123"这类输入 - 脏数据放大问题：
"123abc"转成123，"abc123"转成0，关联结果不可靠
真正难的不是写 CAST，而是让四要素完全对齐：字段类型、字符集、COLLATION、是否 NOT NULL。少一个，索引就安静地躺在那里，却永远不被使用。
