TRIM()最省事但兼容性差，SQL Server 2017+和MySQL 5.7+/PostgreSQL支持，Oracle无TRIM()；LTRIM()/RTRIM()更稳妥，全库兼容，但仅处理ASCII空格且不压缩中间空格。

直接说结论：用 TRIM() 最省事，但要注意数据库兼容性；LTRIM() 和 RTRIM() 更稳妥，尤其在 SQL Server 或旧版 MySQL 中。

TRIM() 在不同数据库里的行为差异

MySQL 5.7+ 和 PostgreSQL 原生支持标准 TRIM() 语法，比如 TRIM(' abc ') → 'abc'；但 SQL Server 直到 2017 才加入 TRIM()，2016 及更早版本会报错 Invalid column name 'TRIM'。Oracle 则压根没有 TRIM()，只有 RTRIM()/LTRIM()。

• 想写一次 SQL 跑多库？优先用 RTRIM(LTRIM(col))，兼容性最强
• MySQL 8.0+ 可用 TRIM(BOTH FROM col) 显式声明方向，避免歧义
• 如果要去掉的不是空格而是其他字符（如 '*'），TRIM('*' FROM col) 在 MySQL/PostgreSQL 有效，SQL Server 仍得靠 REPLACE() 套娃

WHERE 条件里用 TRIM() 容易踩的性能坑

直接写 WHERE TRIM(name) = 'John' 会导致全表扫描——因为函数作用于字段后，索引失效。哪怕 name 字段建了索引也没用。

• 真正要查「值为 John 但可能带空格」的数据，改用 WHERE name LIKE 'John' OR name LIKE ' John' OR name LIKE 'John ' OR name LIKE ' John '（配合 LENGTH() 过滤长度异常的）
• 或者提前在应用层或 ETL 阶段用 UPDATE table SET name = TRIM(name) 清洗并重建索引
• MySQL 8.0+ 支持函数索引：CREATE INDEX idx_trimmed_name ON table (TRIM(name))，但注意这索引只对显式调用该函数的查询生效

LTRIM() 和 RTRIM() 处理不可见字符时的局限

这两个函数只认 ASCII 空格（CHAR(32)），对换行符（CHAR(10)）、回车（CHAR(13)）、制表符（CHAR(9)）或不间断空格（CHAR(160)）完全无效。

• SQL Server 示例：必须写成 RTRIM(LTRIM(REPLACE(REPLACE(col, CHAR(10), ''), CHAR(13), '')))
• MySQL 8.0+ 可用正则： REGEXP_REPLACE(col, '[[:space:]]+', '')，但这是全局替换，不单是首尾
• 最保险的做法：先用 HEX(col) 查看实际字节，确认有哪些控制字符，再针对性 REPLACE()

UPDATE 语句中误用 TRIM() 导致数据截断

执行 UPDATE user SET nickname = TRIM(nickname) 看似安全，但如果字段定义是 VARCHAR(10)，而原始值是 ' 你好 '（UTF-8 下占 8 字节），TRIM 后变成 '你好'（4 字节），一般不会出问题；但若字段含 emoji 或四字节 UTF-8 字符，长度计算容易翻车。

• 务必先检查目标字段的字符集和最大长度：SHOW COLUMNS FROM user LIKE 'nickname'
• 生产环境执行前加 SELECT id, nickname, LENGTH(nickname), LENGTH(TRIM(nickname)) FROM user WHERE LENGTH(nickname) != LENGTH(TRIM(nickname)) LIMIT 5 验证效果
• 别忽略 NULL 值：TRIM(NULL) 结果仍是 NULL，但 ''（空字符串）会被保留——这两者在业务逻辑里常被混为一谈

真正麻烦的从来不是空格本身，而是你不知道它是不是空格——可能是 CHAR(160)、CHAR(8201)（窄空格），甚至 BOM 头。动手前先 SELECT HEX(col) FROM table LIMIT 1，比猜强得多。