TRIM函数默认去除字符串首尾空格，但兼容性差异大：MySQL 8.0+/PostgreSQL/SQL Server 2017+支持标准TRIM()，旧版SQL Server需用RTRIM(LTRIM(col))，SQLite仅支持无参TRIM；且均不处理制表符、换行符、全角空格等非ASCII空白字符。
TRIM函数的基本用法和兼容性差异
SQL标准里的 TRIM() 函数确实能去掉字符串两端空格，但各数据库实现差别很大——MySQL 8.0+、PostgreSQL、SQL Server 2017+ 支持标准语法；而旧版 SQL Server 只认 LTRIM() 和 RTRIM()，SQLite 则默认只支持无参数的 TRIM()（即仅去空格），不支持指定字符。
标准写法是 TRIM([BOTH | LEADING | TRAILING] [characters FROM] string)，但多数场景只需最简形式：
-
TRIM(' hello ')→'hello'（去空格，MySQL/PG/Oracle 都行） -
TRIM(BOTH 'x' FROM 'xxxhelloxxx')→'hello'（去指定字符，PG/Oracle 支持，MySQL 要用TRIM('x' FROM 'xxxhelloxxx')） - SQL Server 2016 及更早版本必须写成
RTRIM(LTRIM(' hello '))
为什么不能只用LTRIM或RTRIM？常见误用场景
单独用 LTRIM() 或 RTRIM() 只能解决单侧问题，实际数据常混杂两端空格，比如用户输入、CSV 导入、日志拼接等场景。若只清左侧，右侧换行符或制表符仍残留；只清右侧，左侧可能有不可见的全角空格或零宽空格（U+3000）。
典型错误现象：
- WHERE 条件匹配失败：例如
WHERE name = TRIM('张三 ')查不到记录，因为原始字段其实是' 张三 ' - GROUP BY 分组异常：两个看似相同的字符串因首尾空格被当作不同值
- JOIN 关联失效：关联字段一侧带空格，另一侧不带，导致结果为空
处理非空格空白字符：制表符、换行符、全角空格
TRIM() 默认只处理 ASCII 空格（U+0020），对 \t、\n、\r 或中文全角空格（U+3000）无效。这时候得靠替换 + 嵌套：
PostgreSQL 示例：
TRIM(
BOTH FROM
REPLACE(
REPLACE(
REPLACE(col, E'\t', ''),
E'\n', ''),
E'\r', '')
)
MySQL 8.0+ 可用正则：
TRIM(BOTH FROM REGEXP_REPLACE(col, '[[:space:]]', ''))
但注意：REGEXP_REPLACE 会把所有空白字符（包括中间的）全干掉，如需保留中间空格，只能分步 REPLACE 或用存储过程封装。
UPDATE语句中使用TRIM要小心性能和NULL
直接在 UPDATE 里用 TRIM() 修改字段值很常见，但有两个坑：
- 如果字段本身为
NULL，TRIM(NULL)结果仍是NULL，不会报错但也不起作用——需加WHERE col IS NOT NULL显式过滤 - 对大表执行
UPDATE ... SET col = TRIM(col)会锁表、触发索引重建、产生大量 binlog，建议加WHERE col != TRIM(col)条件避免无谓更新 - 某些数据库（如 Oracle）对
TRIM()字段建索引时，函数索引需显式声明为TRIM(col)，否则WHERE TRIM(col) = 'x'无法走索引
真正麻烦的是嵌套空白：比如字符串末尾是空格+换行+空格，TRIM() 一次调用就能清完；但若中间夹着不可见控制字符，就得先识别再针对性清理——这时候光靠 TRIM() 不够，得结合 DUMP()（Oracle）、ENCODE()（PG）或十六进制查看工具定位。
