trim函数跨数据库兼容性差：mysql和postgresql支持trim(col)和trim(' ' from col)，sql server 2017+需显式trim(' ' from col)，oracle要求trim(both ' ' from col)且仅支持单字符；ltrim(rtrim(col))最兼容老版本；update须加where remark != trim(remark)避免全表误更新；trim对全角空格、制表符等无效，需结合replace或正则处理。
TRIM函数在不同数据库中的写法差异
MySQL、PostgreSQL、SQL Server（2017+）和Oracle都支持TRIM()，但语法细节不统一。最易出错的是参数顺序和默认行为：MySQL和PostgreSQL中TRIM(' ' FROM col)等价于TRIM(col)，而SQL Server要求显式指定TRIM(' ' FROM col)，不支持无参数形式；Oracle的TRIM()只接受单字符，且必须用BOTH/LEADING/TRAILING关键字，比如TRIM(BOTH ' ' FROM col)。
如果你写TRIM(col)却在SQL Server里执行，会直接报错：Incorrect syntax near '('；在Oracle里则提示ORA-30001: trim set should have only one character。
实际建议统一用带参数的写法，避免跨库迁移时翻车：
SELECT TRIM(' ' FROM name) AS name_clean FROM users;
为什么LTRIM(RTRIM())比TRIM()更兼容
老版本SQL Server（2016及以前）、SQLite、以及部分嵌入式数据库压根不支持TRIM()。这时LTRIM(RTRIM(col))是唯一稳妥选择——它在几乎所有SQL引擎中都可用，语义明确，且性能差异几乎可忽略（现代优化器通常会把嵌套函数合并为一次扫描）。
注意两点：
-
RTRIM()只处理右侧空格，CHAR(9)（制表符）或CHAR(10)（换行）不会被清除 - 如果字段含全角空格（U+3000），
LTRIM/RTRIM和标准TRIM都无效，得用REPLACE(col, NCHAR(12288), '')额外处理
UPDATE时忘记WHERE条件导致全表误更新
清洗数据最常踩的坑不是函数写错，而是执行UPDATE时漏掉WHERE。比如想只修status = 'pending '的记录，却写了：
UPDATE orders SET remark = TRIM(remark); -- 危险！全表remark都被去空格
正确做法是先用SELECT验证逻辑：
SELECT id, remark, TRIM(remark) AS trimmed FROM orders WHERE remark != TRIM(remark) LIMIT 5;
确认结果无误后再执行带条件的更新：
UPDATE orders SET remark = TRIM(remark) WHERE remark != TRIM(remark);
另外，某些数据库（如MySQL）在严格模式下，若TRIM()后结果为空字符串且字段为NOT NULL，可能触发警告而非报错，容易被忽略。
空格类型不止ASCII 32，多字节字符要单独处理
用户粘贴数据时可能混入不可见字符：全角空格（U+3000）、不间断空格（U+00A0）、零宽空格（U+200B）等。TRIM()和LTRIM/RTRIM对这些一律失效。
判断是否存在异常空格，可用长度对比：
SELECT remark, LENGTH(remark), LENGTH(TRIM(remark)) FROM users WHERE LENGTH(remark) > LENGTH(TRIM(remark));
若差值非1，大概率存在多字节空格。修复需结合REPLACE()：
UPDATE users SET remark = REPLACE(REPLACE(remark, NCHAR(160), ''), NCHAR(12288), ''); -- 清除不换行空格和全角空格
真正麻烦的是零宽字符——它们不占显示宽度，LENGTH()也统计不到，只能靠正则（如PostgreSQL的REGEXP_REPLACE）或应用层预处理。
别指望一个TRIM()解决所有“看起来像空格”的问题。先搞清数据来源，再决定要不要上正则或ETL工具。
