join字段类型不一致会导致索引失效，因数据库隐式转换使被转换侧索引无法使用；mysql可能静默转换，postgresql常报错，sql server则按优先级转换并可能报错。
JOIN字段类型不一致会直接让索引失效
MySQL、PostgreSQL、SQL Server 都会在 JOIN 条件中对类型不匹配的字段做隐式转换，但转换方向取决于两边类型优先级——通常把低优先级类型转成高优先级类型。问题在于：被转换的一侧如果原本有索引，转换后就无法走索引了。
比如 user.id 是 BIGINT，order.user_id 是 VARCHAR(20)，执行 JOIN ... ON user.id = order.user_id 时，MySQL 会把 user.id 转成字符串去比对，导致 user.id 的主键索引失效；而 PostgreSQL 可能干脆报错或拒绝隐式转换。
- MySQL 5.7+ 默认开启
STRICT_TRANS_TABLES后，部分隐式转换会被拦截，但 JOIN 场景仍常静默转换 - PostgreSQL 对类型强制更严格，
INTEGER = TEXT直接报错：operator does not exist: integer = text - SQL Server 会按数据类型优先级表转换（比如
int优先级高于varchar），把varchar列转成int—— 若含非数字字符，直接报Conversion failed when converting the varchar value 'abc' to data type int.
如何快速发现 JOIN 类型不匹配的问题
别等线上慢查询报警才查。在写 JOIN 前，先确认两边字段的精确类型，尤其注意常见“伪装一致”陷阱：
-
INT和SMALLINT看似兼容，但跨库同步或 ORM 映射时可能被误标为不同类型 -
VARCHAR(16)和CHAR(16)在 MySQL 中比较会补空格，但索引行为不同；PostgreSQL 中CHAR会自动 rtrim，行为更隐蔽 - 带时区的
TIMESTAMP WITH TIME ZONE和无时区的TIMESTAMP WITHOUT TIME ZONE在 PostgreSQL 中不能直接 JOIN，必须显式AT TIME ZONE - 用
EXPLAIN看执行计划：MySQL 中若出现type: ALL或key: NULL，且 JOIN 字段本应走索引，大概率是类型转换导致
安全 JOIN 的实操守则
不依赖数据库自动转换，把类型对齐动作显式写出来，既可控又可读：
- 优先改表结构：用
ALTER TABLE统一字段类型，这是最彻底的解法。哪怕只是加个COMMENT '来源自 user.id'也能帮后续人理解设计意图 - 实在不能改表，用显式转换函数兜底：
ON user.id = CAST(order.user_id AS BIGINT)（PostgreSQL/SQL Server）或ON user.id = CONVERT(BIGINT, order.user_id)（SQL Server）；MySQL 推荐用ON user.id = order.user_id + 0（仅限纯数字字符串）但不推荐，易出错 - 避免在 JOIN 条件里用函数包裹索引字段，例如
ON DATE(created_at) = DATE(other_date)—— 这会让created_at索引完全失效 - 使用 ORM 时检查生成 SQL：Django 的
select_related、Rails 的joins、MyBatis 的<join></join>标签都可能因模型字段类型声明不准，生成错误类型 JOIN
跨数据库迁移时最容易翻车的类型坑
从 MySQL 迁到 PostgreSQL 或 ClickHouse 时，原来“能跑”的 JOIN 会突然报错或变慢，核心是因为类型系统差异更大：
- MySQL 把
'123 '（带空格）和123当相等；PostgreSQL 不会，且CHAR类型存储会补空格，但比较时不自动 trim - ClickHouse 的
UInt64和 MySQL 的BIGINT UNSIGNED看似对应，但 JOIN 时若一边是Int64，ClickHouse 会拒绝隐式转换，报Cannot convert Int64 to UInt64 - SQLite 没有真正的类型约束，
id INTEGER字段存字符串也行，但和其他库 JOIN（如通过联邦查询）时，类型协商失败概率极高 - 所有数据库对 JSON 字段 JOIN 都极不友好：MySQL 的
JSON、PostgreSQL 的JSONB、SQL Server 的NVARCHAR(MAX)存 JSON，都不能直接用于高效 JOIN —— 必须先提取成标量字段并建函数索引
类型对齐不是上线前才做的事，而是建表时就要约定好上下游字段语义和物理类型。一旦松动，后面每个 JOIN 都像在薄冰上跳踢踏舞。
