TRIM函数跨数据库语法不一致：MySQL支持TRIM(col)和TRIM(BOTH ' ' FROM col)，PostgreSQL需显式TRIM(' ' FROM col)且不支持无参形式，SQL Server 2017+才支持TRIM()，旧版须用LTRIM(RTRIM(col))。
TRIM 函数在不同数据库里怎么写才不报错
mysql、postgresql、sql server 的 trim 行为不一致，直接照搬会出错。mysql 5.7+ 支持 trim(both ' ' from col) 和简写 trim(col)；postgresql 要求显式指定 trim(' ' from col)，不支持无参数形式；sql server 直到 2017 才加 trim()，旧版本只能用 ltrim(rtrim(col))。
常见错误现象：TRIM(col) 在 PostgreSQL 报错 “function trim(character varying) does not exist”，在 SQL Server 2016 及更早版本提示 “'TRIM' is not a recognized built-in function name”。
- 使用场景：清洗用户输入的姓名、地址、邮箱等字符串字段
- 参数差异：PostgreSQL 和 Oracle 支持
TRIM(LEADING '0' FROM col)去前导零，MySQL 不支持这种语法 - 性能影响：所有主流数据库对
TRIM都是逐行计算，WHERE 条件中用TRIM(col) = 'abc'会导致索引失效
UPDATE 语句里用 TRIM 清洗数据要加 WHERE 条件
直接 UPDATE table SET col = TRIM(col) 看似省事，实际可能把原本就干净的数据也重写一遍，触发不必要的行锁、日志写入和复制延迟（尤其在主从架构中）。
正确做法是只更新“确实含空格”的行：
UPDATE users SET name = TRIM(name) WHERE name != TRIM(name);
这个判断在多数数据库中能走索引（如果 name 有索引），且逻辑清晰——只有 Trim 前后不等，才说明存在首尾空格。
- 容易踩的坑：用
WHERE name LIKE ' %' OR name LIKE '% '漏掉中间有多个空格但首尾各一个的情况；更糟的是用WHERE name LIKE '% %'，会误伤正常含空格的姓名（如 “Mary Jane”） - 兼容性注意：SQL Server 中
!=可换成<>，效果相同
清洗脚本验证时别只查 SELECT，得看 UPDATE 影响行数
很多人写完清洗 SQL，先 SELECT id, name, TRIM(name) FROM users WHERE name != TRIM(name) 看几条样例就直接执行 UPDATE，结果发现改了上万行，其中大量是前后端已处理过的中间表或缓存字段，白忙活还引发下游异常。
验证必须分两步：
- 第一步：用
SELECT COUNT(*)确认待清洗行数是否符合预期（比如“注册表中约 3% 用户名带空格”，而不是“全表 80% 都要改”） - 第二步：在测试库跑完整
UPDATE后，立刻查SELECT COUNT(*) FROM users WHERE name != TRIM(name)，确认残余为 0；再抽样比对id和原始值，防止意外截断（比如CHAR类型字段隐式补空格） - 别忽略 NULL：
TRIM(NULL)还是 NULL，但WHERE name != TRIM(name)对 NULL 不成立（因为 NULL != NULL 为 UNKNOWN），所以不会误触，这点可以放心
真正要清洗的不只是空格：制表符、换行符、全角空格也得一并处理
TRIM() 默认只处理 ASCII 空格（U+0020），对 \t、\n、全角空格（U+3000）完全无效。用户从 Excel 或微信粘贴进来的数据，经常混着这些字符。
实操建议：
- PostgreSQL 可用
REGEXP_REPLACE(col, '[\s\u3000]+', '', 'g')（\s包含 tab、换行、回车等） - MySQL 8.0+ 支持正则，用
REGEXP_REPLACE(col, '[[:space:]\u3000]', '')；老版本只能嵌套REPLACE(REPLACE(REPLACE(col, '\t', ''), '\n', ''), '\r', '') - SQL Server 用
REPLACE(REPLACE(REPLACE(REPLACE(col, CHAR(9), ''), CHAR(10), ''), CHAR(13), ''), NCHAR(12288), '')（NCHAR(12288)是全角空格） - 性能提醒：正则替换比
TRIM慢得多，批量清洗时优先考虑应用层处理，SQL 层只做兜底
最常被忽略的点：全角空格在 WHERE 条件里看起来和普通空格一样，但 = 判断会失败，导致清洗脚本“看似运行成功，其实一条没清”。
