JOIN字段类型不一致会导致隐式转换，使索引失效、触发全表扫描；还需同时检查字符集/collation、NULL处理、索引结构及统计信息五层。
JOIN字段类型不一致会强制隐式转换
MySQL、PostgreSQL等主流数据库在ON条件中发现左右表字段类型不匹配（比如user_id INT vs log.user_id VARCHAR），会尝试隐式转换——通常是把数字转成字符串，或把字符串按规则转成数字。这个过程无法使用索引，导致全表扫描。
- 常见错误现象：
EXPLAIN结果里出现type: ALL或Extra: Using where; Using join buffer，哪怕字段上明明建了索引 - 典型场景：日志表用
VARCHAR存订单号（含字母前缀），主表用BIGINT存ID，但JOIN时没加类型校验 - 隐式转换方向取决于SQL标准和引擎实现：MySQL倾向把“窄类型”转为“宽类型”，PostgreSQL则更严格，常直接报错
operator does not exist
字符集或排序规则（collation）不同也会失效
即使都是VARCHAR，若两边字段的collation不同（比如utf8mb4_0900_ai_ci vs utf8mb4_unicode_ci），MySQL仍可能放弃索引。PostgreSQL虽不依赖collation做JOIN，但若涉及LIKE或函数包裹，则同样触发序列扫描。
- 检查方法：执行
SHOW CREATE TABLE table_name，比对COLLATE值；PostgreSQL查pg_attribute视图中的attcollation - 修复不是简单改表：需先确认业务是否允许统一collation，否则可能影响大小写敏感逻辑（如
login_name校验） - 临时绕过：显式用
CONVERT(... USING ...)或COLLATE强制对齐，但会增加CPU开销，且不能解决索引失效根本问题
NULL值处理不当引发额外过滤
当JOIN字段存在大量NULL，而类型又不一致时，数据库可能把NULL = NULL的语义和类型转换混在一起判断，导致优化器误判选择嵌套循环而非哈希连接，尤其在SQL Server和旧版MySQL中明显。
- 表现特征：小表驱动大表时性能尚可，但一旦两表都超10万行，执行时间呈指数增长
- 容易被忽略的点：JSON字段里提取的ID（如
JSON_EXTRACT(log.extra, '$.order_id')）默认返回JSON类型，与INTJOIN时既类型不匹配，又自带NULL风险 - 实操建议：JOIN前先用
WHERE field IS NOT NULL预过滤，或用COALESCE(field, 0)兜底（注意0是否业务合法值）
索引本身存在但未被选中
类型匹配、collation一致、无NULL干扰——这时还要看索引是否真的“可用”。例如字段是TINYINT但值范围实际只用到0~2，优化器可能认为索引区分度太低而弃用；或者复合索引顺序和JOIN条件顺序不一致（如索引是(status, user_id)，但JOIN只用了user_id）。
- 验证方式：用
EXPLAIN FORMAT=JSON查看used_key_parts和key_length，确认是否命中预期字段 - 特别注意：PostgreSQL中
text字段建B-tree索引默认不支持前缀查询，若JOIN条件带LEFT(user_id, 10)，索引完全无效 - 不要迷信
ANALYZE TABLE：统计信息更新后仍可能因数据倾斜（如95%记录user_id = 0）导致执行计划退化
类型对齐这事看着简单，但实际要同时盯住字段定义、字符集、NULL语义、索引结构、统计信息五层，少查一层就可能卡在慢查询里出不来。
