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 时没验证实际变化行数——这些地方一跳过去，数据看起来“干净”了，其实逻辑还是错的。