TRIM函数在不同数据库中语法差异大：MySQL 5.7仅支持TRIM(col)，8.0+和PostgreSQL支持TRIM(BOTH 'x' FROM col)，SQL Server 2017+才支持TRIM()且不支持BOTH/LEADING/TRAILING；它默认只处理ASCII空格，对制表符、全角空格等无效；在JOIN或WHERE中使用TRIM会导致索引失效、性能下降；LTRIM/RTRIM虽兼容性好但语义不等价于TRIM；TRIM不能替代全面数据清洗。
TRIM函数在不同数据库中的写法差异
MySQL、PostgreSQL 和 SQL Server 对 TRIM 的支持程度不同，直接照搬语法容易报错。MySQL 8.0+ 支持标准 TRIM(BOTH ' ' FROM col)，但 MySQL 5.7 只认简写 TRIM(col)；PostgreSQL 从 9.6 开始支持完整语法，而 SQL Server 直到 2017 才引入 TRIM()，且不支持 BOTH/LEADING/TRAILING 子句。
实际使用前先确认数据库版本和方言：
- MySQL 5.7：只能用
TRIM(col)，默认去前后空格 - MySQL 8.0+ 或 PostgreSQL：可用
TRIM(BOTH 'x' FROM col)去指定字符 - SQL Server 2016 及更早：必须用
RTRIM(LTRIM(col))
为什么不能只依赖 TRIM 处理“看起来像空格”的字符
TRIM 默认只处理 ASCII 空格（U+0020），对制表符 、换行符
、全角空格（U+3000）、零宽空格（U+200B）完全无效。这类字符常出现在 Excel 导入或爬虫数据中，表面看字段“没空格”，实际查不到或连不上关联表。
应对方法：
- PostgreSQL 可用
REGEXP_REPLACE(col, E'[\s\u3000\u200B]+', '', 'g') - MySQL 8.0+ 可用
REGEXP_REPLACE(col, '[[:space:]]|[\u3000\u200B]', '') - SQL Server 建议用自定义函数或应用层清洗，
REPLACE嵌套最多支持三级，再深就难维护
在 JOIN 或 WHERE 中误用 TRIM 导致性能暴跌
对字段套 TRIM(name) 后做 JOIN 或 WHERE 匹配，会强制全表扫描——因为索引无法命中函数计算后的结果。哪怕 name 字段上有索引，TRIM(name) = 'abc' 也大概率走不了。
更稳妥的做法：
- 清洗入库时就存干净值：
INSERT INTO t (clean_name) VALUES (TRIM(raw_name)) - 若必须运行时处理，且字段长度固定（如编码类字段），可考虑计算列 + 索引（MySQL 5.7+、SQL Server 2016+ 支持）
- 避免在大表
ON条件里写TRIM(t1.code) = TRIM(t2.code)，优先清洗源数据
TRIM 与 LTRIM/RTRIM 的兼容性陷阱
某些旧系统仍用 LTRIM(RTRIM(col))，它在所有 SQL 方言中都可用，但语义不等价于 TRIM：比如 PostgreSQL 的 TRIM 默认同时处理空格和制表符，而 RTRIM 只处理空格。更隐蔽的问题是，SQL Server 的 RTRIM 对 Unicode 字符串末尾的空格截断不稳定，尤其 NVARCHAR 列含尾随空格时可能被意外保留。
建议：
- 新项目统一用
TRIM（确认数据库版本支持） - 迁移老代码时注意测试边界值：全空格字符串、混合空白字符、NULL 值（
TRIM(NULL)返回 NULL，安全） - 别把
TRIM当万能清洗工具——它只解决最表层的空白问题，嵌套 JSON、HTML 标签、不可见控制字符得靠正则或应用层
TRIM，而是数据里那些你看不见的空白字符，以及它们在索引、JOIN、导出时引发的连锁反应。 
