TRIM函数默认仅去除ASCII空格，不同数据库语法差异大：MySQL支持TRIM(col)，PostgreSQL需TRIM(BOTH FROM col)，SQL Server 2017+才支持TRIM，旧版须用LTRIM(RTRIM(col))；且均不处理制表符、换行符、全角空格等非空格空白字符。
TRIM 函数能直接去掉字符串两端空格，但不同数据库的语法和默认行为差异很大，不加注意容易漏删或报错。
TRIM 在 MySQL、PostgreSQL、SQL Server 中的行为差异
MySQL 的 TRIM() 默认只删空格，支持 BOTH/LEADING/TRAILING 修饰符；PostgreSQL 的 TRIM() 默认也只删空格，但必须显式写 TRIM(BOTH FROM col)，省略 BOTH 会报错；SQL Server 2017+ 才支持标准 TRIM()，旧版本只能用 LTRIM(RTRIM(col))。
- MySQL 示例：
SELECT TRIM(' hello ');→'hello' - PostgreSQL 示例：
SELECT TRIM(BOTH FROM ' hello ')（不能省略BOTH FROM） - SQL Server 2016 及更早：必须写
SELECT LTRIM(RTRIM(col))
TRIM 无法处理制表符、换行符等“隐形空格”
标准 TRIM() 默认只处理 ASCII 空格（U+0020），对 、
、
或全角空格（U+3000）完全无效。这类字符常出现在 Excel 导入或爬虫抓取的数据中，表面看是“空格”，实则查不到、比不了。
- MySQL 中可扩展：
TRIM(BOTH ' ' FROM TRIM(BOTH ' ' FROM TRIM(col))) - PostgreSQL 更灵活：
TRIM(BOTH FROM REGEXP_REPLACE(col, E'[\t\n\r\u3000]+', '', 'g')) - 简单验证是否存在非空格空白符：
SELECT col, LENGTH(col), LENGTH(TRIM(col)) FROM t WHERE LENGTH(col) > LENGTH(TRIM(col));
UPDATE 时用 TRIM 要小心 NULL 和性能影响
TRIM(NULL) 结果仍是 NULL，所以直接 UPDATE t SET col = TRIM(col) 不会改变 NULL 值——这通常是预期行为；但如果字段含大量长文本，频繁用 TRIM() 更新可能触发全表扫描或索引失效，尤其在 WHERE 条件没走索引时。
- 安全写法（避免误更新）：
UPDATE t SET col = TRIM(col) WHERE col IS NOT NULL AND col != TRIM(col); - 带条件批量清理（如只处理以空格开头的）：
WHERE col LIKE ' %' OR col LIKE '% ' - 大表建议先加索引：
CREATE INDEX idx_col_trim ON t ((TRIM(col)));（PostgreSQL 支持表达式索引，MySQL 8.0+ 也支持）
真正麻烦的不是空格本身，而是空格混着不可见字符、数据库版本不统一、以及 UPDATE 时没验证实际变化行数——这些地方一跳过去，数据看起来“干净”了，其实逻辑还是错的。
