JOIN字段类型不一致必然导致隐式转换和索引失效，MySQL静默转换引发全表扫描（type=ALL、key=NULL），PostgreSQL则直接报错；唯一根治方式是ALTER TABLE统一类型、字符集与校对规则，并确保应用层传参类型纯净。
JOIN字段类型不一致会强制隐式转换
只要ON条件里两边字段类型不同，MySQL 或 PostgreSQL 就会悄悄做类型转换——这不是优化器“聪明”，是它不得不兜底。比如user_id是BIGINT，而关联表里对应字段是VARCHAR，每次JOIN都要把整列VARCHAR转成数字，索引直接失效。
常见错误现象：EXPLAIN显示type=ALL或rows远超预期，key为空；PostgreSQL 则可能直接报错operator does not exist。
- MySQL 对隐式转换更激进（比如
'123 '能转成123），但代价是全表扫描+精度风险 - PostgreSQL 更严格，类型不匹配通常拒绝执行，反而更容易暴露问题
- MaxCompute 等引擎在
string和bigintJOIN 时会转为double，导致111111111111111111和111111111111111110被判相等
用EXPLAIN EXTENDED + SHOW WARNINGS查隐式转换
光看EXPLAIN的key列不够，得揪出优化器实际执行的语句。MySQL 下必须组合两个命令才能看到是否被改写：
先跑EXPLAIN EXTENDED SELECT ... JOIN ...，立刻跟一句SHOW WARNINGS——里面Message字段会明说类似Cast to BIGINT或CONVERT(user_id USING utf8mb4)。
PostgreSQL 用EXPLAIN (VERBOSE, ANALYZE) SELECT ...，关注Output和Filter字段是否出现::integer或text::bigint。
- ORM（如 Django ORM）生成的 SQL 带参数占位符，
EXPLAIN可能不触发转换逻辑，需用PREPARE/EXECUTE模拟真实执行环境 - 某些数据库（如 TiDB）的
EXPLAIN FORMAT='verbose'也能暴露隐式转换，但行为不统一，不能只信key非空
ALTER TABLE对齐字段类型比函数包装更可靠
别想着在 SQL 里用CAST或CONVERT临时绕过——这等于告诉数据库“每次都给我现场算一遍”，索引依然用不上。
正确做法：统一改为相同类型 + 相同字符集 + 相同排序规则。例如两边都是BIGINT UNSIGNED，或都是VARCHAR(32) COLLATE utf8mb4_bin。
- PostgreSQL 中
ALTER COLUMN TYPE BIGINT USING id::BIGINT虽能执行，但如果原字段有空格或非数字字符，会直接报错中断 - MySQL 的
MODIFY可能静默截断，比如把VARCHAR(64)改成INT时丢掉超长值 - 修改主键或外键字段类型需先删约束，改完再加回；线上操作务必评估锁表时间，不能停服时建议用影子表+触发器同步过渡
应用层传参也要保持类型纯净
数据库字段对齐了，但代码里还是把数字 ID 当字符串拼进 SQL，WHERE 和 JOIN 仍会触发隐式转换。
例如 Python 的 cursor.execute("SELECT * FROM users JOIN orders ON users.id = %s", [str(user_id)])，哪怕 users.id 是 BIGINT，传入字符串也会让优化器放弃索引。
- ORM 框架（如 SQLAlchemy、MyBatis）要确认参数绑定是否保留原始类型，避免自动 toString()
- HTTP 接口接收的 ID 参数，解析后应显式转为整型再传给查询逻辑，而不是留着字符串走到底
- 前端传参也需约定：ID 类字段用 number 类型，避免 JSON 序列化时变成字符串
真正卡住性能的往往不是没加索引，而是字段类型看着一样、实则字符集或符号性不一致；这类问题在上线后才爆发，且很难通过慢日志直接定位。
