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，比猜强得多。
