explain中type=all、key=null是隐式转换的铁证，表明join字段类型不一致导致索引失效；mysql静默转换引发错关联，postgresql报错后强制转换仍无法走索引，根治需统一物理类型、字符集与collate，并校验脏数据及应用层传参。
EXPLAIN里type=ALL、key=NULL就是隐式转换的铁证
看到这两个指标，基本可以断定JOIN字段类型不一致。MySQL不会告诉你“我做了隐式转换”，而是直接放弃索引——它把数字列转成字符串去比对VARCHAR字段，或反过来把字符串全量CAST成数字，结果就是B+树索引完全失效。PostgreSQL更狠，直接报错operator does not exist: integer = text，但加了::BIGINT后依然走不了索引，因为函数作用于索引列，优化器无法下推定位。
别在ON里写CAST、CONVERT或::转换
显式转换看似可控，实则坐实索引不可用。MySQL里ON u.id = CAST(o.user_id AS SIGNED)、PostgreSQL里ON u.id = o.user_id::BIGINT，执行计划里都会出现Filter: ((o.user_id)::bigint = u.id)，说明转换发生在逐行过滤阶段，不是索引查找阶段。
- MySQL中
CONVERT('123 ', SIGNED)会静默截掉尾部空格，但'abc'变成0，关联错乱 - PostgreSQL遇到
'U123'或'123 '直接报错invalid input syntax for integer - SQL Server里
CAST(customers.id AS INT)同样让customers.id上的索引失效
真正该做的三件事：改表结构、查脏数据、校验传参
根治不是写更复杂的SQL，而是让字段物理定义对齐：
- 统一类型：
ALTER TABLE orders MODIFY user_id BIGINT（MySQL）或ALTER TABLE orders ALTER COLUMN user_id TYPE BIGINT USING user_id::BIGINT（PostgreSQL），注意后者遇非数字直接中断 - 先扫脏数据：
SELECT COUNT(*) FROM orders WHERE user_id REGEXP '[^0-9]'（MySQL）或SELECT COUNT(*) FROM orders WHERE user_id !~ '^[0-9]+$'（PostgreSQL） - 应用层传参必须干净：Java用
SqlParameter("@id", SqlDbType.BigInt)，Python用cursor.execute("SELECT * FROM t WHERE id = %s", (123,))，绝不能传"123"进INT字段
字符集和COLLATE不一致也会触发隐式转换
哪怕两边都是VARCHAR(32)，只要Collation不同（比如utf8mb4_0900_as_cs vs utf8mb4_unicode_ci），MySQL仍会悄悄做CONVERT(USING utf8mb4)，导致索引跳过。验证命令：SHOW FULL COLUMNS FROM table_name LIKE 'field_name'，比对Collation列。
- 临时绕过可用
ON a.name = b.name COLLATE utf8mb4_unicode_ci，但只是换CPU开销保运行，不解决性能问题 - 根治要批量修正：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 跨库JOIN时尤其危险——两个库默认字符集可能不同，连
SHOW CREATE TABLE都看不出问题
最麻烦的不是改字段类型，而是改完发现业务逻辑依赖前导空格或大小写敏感；这时候COLLATE不能随便动，得配合应用层做兼容处理。隐式转换藏得深，但只要盯住EXPLAIN输出和字段定义差异，就能快速切中要害。
