TRIM()默认仅去除首尾ASCII空格，不处理制表符、换行符、全角空格等；需显式指定字符或改用正则、REPLACE等方案，并注意空值、空字符串及索引失效风险。
TRIM函数的基本用法和默认行为
TRIM() 在多数主流数据库（如 PostgreSQL、SQL Server 2017+、MySQL 8.0+、SQLite）中默认只去掉字符串**首尾的空格**，不处理制表符、换行符或全角空格。它不是万能“去杂字符”工具，这点常被误判。
常见错误现象：SELECT TRIM(' \t\nhello world\r\n ') 在 PostgreSQL 中返回 ' \nhello world\r\n'（制表符和换行仍在），因为默认只认 ASCII 空格（U+0020）。
- MySQL 5.7 及更早版本不支持标准
TRIM()语法，必须写成TRIM(both ' ' from col)或直接用TRIM(col)（此时仅去空格） - Oracle 的
TRIM()默认也只处理空格，但不支持TRIM(BOTH FROM ...)的省略写法，必须显式写TRIM(' ' FROM col) - 如果字段含全角空格（
U+3000），所有数据库的默认TRIM()都无感——得靠REPLACE()或正则
如何安全去掉首尾所有空白字符（含 tab、换行等）
标准 SQL 没有内置“去所有空白”的 TRIM() 变体，必须组合或改用方言函数。关键是别假设 TRIM() 能覆盖所有空白。
PostgreSQL 示例（推荐）：
SELECT TRIM(BOTH '\t\n\r\x00 ' FROM col) FROM t;其中
'\t\n\r\x00 ' 显式列出要移除的字符；注意 \x00 是 null 字符，某些导入数据会混入。
- MySQL 8.0+ 可用正则：
REGEXP_REPLACE(col, '^[[:space:]]+|[[:space:]]+$', '')，但性能比TRIM()差，大数据量慎用 - SQL Server 推荐先用
REPLACE(REPLACE(REPLACE(col, CHAR(9), ''), CHAR(10), ''), CHAR(13), '')去控制符，再套RTRIM(LTRIM(...)) - 避免嵌套多层
TRIM(TRIM(TRIM(...)))——既难读又没解决根本问题
UPDATE 时用 TRIM 要防空值和不可逆修改
TRIM(NULL) 返回 NULL，这没问题；但真正容易出事的是：原字段为 ''（空字符串）时，TRIM('') 还是 ''，看起来没变，可如果业务逻辑把空字符串当“未填写”，清理后仍为空，就掩盖了真实数据问题。
- 执行前务必加
WHERE col IS NOT NULL AND col != ''条件，避免无谓更新（尤其大表） - 对
CHAR(n)类型字段，TRIM()后长度可能变化，若该列有唯一索引或外键约束，需确认是否触发隐式类型转换或截断 - 生产环境执行前，先用
SELECT col, TRIM(col) AS trimmed FROM t WHERE ... LIMIT 5;抽样验证效果
TRIM 和 LTRIM/RTRIM 的性能与兼容性取舍
纯去左侧或右侧空格时，TRIM(LEADING ...) 和 TRIM(TRAILING ...) 语义清晰，但老系统（如 SQL Server 2016 或旧版 MySQL）可能不支持，只能退化用 LTRIM() / RTRIM()。
-
TRIM(LEADING ' ' FROM col)和LTRIM(col)在功能上等价，但前者是标准 SQL，后者是厂商扩展——跨库迁移时后者更易出错 - SQLite 的
TRIM()不支持指定字符集，只能去空格；若需去其他字符，必须用REPLACE()循环调用（不优雅但有效） - 别在 WHERE 条件里对字段用
TRIM(col) = 'x'——会导致索引失效；应改用col LIKE 'x%' AND col LIKE '%x' AND TRIM(col) = 'x'或建函数索引（如 PostgreSQL 支持）
空格之外的“空白”从来不是单一字符，而是一组 Unicode 类别；TRIM() 的边界恰恰在这里：它只做精确字符匹配，不按语义识别“空白”。真要彻底清理，得结合业务场景选正则、循环替换或应用层预处理。
