MySQL比较VARCHAR/CHAR时自动忽略尾部空格，而PostgreSQL、SQL Server、Oracle默认严格字节比对，导致跨库JOIN失效；应使用HEX()检查真实字节、同步TRIM()并处理NULL、警惕CHAR填充与索引失效。
MySQL里尾部空格被自动忽略，但其他数据库不会
MySQL的VARCHAR和CHAR在比较时会自动忽略尾部空格（这是SQL标准允许的“padding behavior”），所以'adu ' = 'adu'返回TRUE；但PostgreSQL、SQL Server、Oracle默认严格按字节比对，'adu ' ≠ 'adu'。这意味着同一段JOIN语句在MySQL能跑通，在别的库直接失联。
别靠肉眼判断字段是否“看起来一样”，用HEX(col)查真实字节内容：HEX('adu ')在MySQL返回61647520（末尾有20，即空格），而HEX('adu')是616475——只要HEX结果不同，就不可能匹配。
- 确认数据库行为：查
SELECT @@sql_mode（MySQL）或文档确认是否启用了PAD_CHAR_TO_FULL_LENGTH - 跨库迁移或混合查询时，一律按“严格比对”逻辑写ON条件，别依赖MySQL的宽松特性
- 如果必须兼容MySQL又想保持语义一致，显式用
RTRIM()而非依赖隐式截断
JOIN条件里只TRIM一边等于没做
ON a.key = TRIM(b.key)这种写法毫无意义——左表还是带空格的原始值，右表被清洗了，但两边根本不对等。JOIN失败不是因为“某一边脏”，而是因为“两边不一致”。
必须同步清洗：ON TRIM(a.key) = TRIM(b.key)才是基础操作。但要注意：TRIM(NULL)仍是NULL，而NULL = anything永远为UNKNOWN，所以含NULL的行照样被过滤掉。
- 安全写法是：
ON COALESCE(TRIM(a.key), '') = COALESCE(TRIM(b.key), '') - 如果业务上认为空字符串和NULL都代表“无值”，改用
ON NULLIF(TRIM(a.key), '') = NULLIF(TRIM(b.key), '') - SQL Server 2016及更早版本不支持
TRIM()，得写成RTRIM(LTRIM(a.key))
TRIM后性能暴跌？函数索引救不了急但能治本
加了TRIM()的JOIN条件无法走普通索引，大表关联时可能从毫秒变分钟。临时方案是加函数索引，但不是所有库都支持，且建索引本身有成本。
MySQL 8.0+、PostgreSQL、SQL Server 2016+支持函数索引，例如：CREATE INDEX idx_trimmed_code ON orders (TRIM(order_code))。但注意：该索引只对WHERE TRIM(order_code) = ?或ON TRIM(a.code) = TRIM(b.code)生效，对WHERE order_code = ?无效。
- 建之前先确认字段NULL比例：
SELECT COUNT(*) FILTER (WHERE code IS NULL) * 100.0 / COUNT(*) FROM orders - 函数索引不加速
ORDER BY TRIM(code)，排序仍需额外计算 - 真正长期解法是入库时就
TRIM()并校验，而不是把清洗逻辑堆在查询层
别忘了CHAR类型自带空格陷阱
如果连接字段是CHAR(10)，哪怕存的是'abc'，数据库也会自动右补7个空格变成'abc '；而另一张表若用VARCHAR(10)存'abc'，就真只是'abc'。这时候TRIM()能救，但更隐蔽的问题是：CHAR字段在JOIN时可能触发隐式转换，尤其当另一字段是数字类型。
- 用
DATA_TYPE和CHARACTER_MAXIMUM_LENGTH查真实定义：SELECT column_name, data_type, character_maximum_length FROM information_schema.columns WHERE table_name = 'orders' AND column_name = 'code' - CHAR字段优先转成VARCHAR再JOIN：
CAST(a.code AS VARCHAR(10))比TRIM(a.code)更彻底 - 如果发现两边一个是CHAR、一个是VARCHAR，且长度差异大，先检查是否该统一类型，而不是硬补空格
实际最常踩的坑不是不会写TRIM()，而是以为“我TRIM了，问题就没了”，却没意识到NULL、CHAR填充、跨库行为差异、索引失效这四层叠加效应。处理前务必用HEX()和LENGTH()看一眼真实数据长什么样，比猜强十倍。
