必须嵌套使用RTRIM(LTRIM(col))才能清除两端空格，因LTRIM/RTRIM仅单侧生效且只处理ASCII空格，对制表符、换行符、全角空格等完全无效；单独使用会导致WHERE匹配失败、GROUP BY分组异常、JOIN关联失效等问题。
直接用 LTRIM() 去左、RTRIM() 去右，但必须嵌套使用才能清两端；单独调用只解决单侧问题，且对制表符、换行符、全角空格完全无效。
为什么不能只用 LTRIM() 或只用 RTRIM()
常见错误是只清一侧，比如写 WHERE LTRIM(name) = 'Alice'，结果右侧仍残留 \r 或空格，导致匹配失败。典型现象包括：
-
GROUP BY把'Alice '和'Alice'当作两个键 -
JOIN时因一侧带空格、另一侧不带而漏关联 - 导出 CSV 后 Excel 显示「看似相同却无法去重」
真正要清两端，必须写成 RTRIM(LTRIM(col)) —— 注意顺序无关，但括号不能少。
LTRIM() 和 RTRIM() 只认 ASCII 空格（U+0020）
它们对以下字符完全无感：
- 制表符
\t（ASCII 9） - 换行符
\n（ASCII 10）、回车符\r（ASCII 13） - 不间断空格
若数据来自 Excel、日志或爬虫，大概率含这些字符。验证方法是：SELECT HEX(col) FROM t WHERE id = 1，看末尾是不是 0D0A 或 A0。修复需叠加 REPLACE()，例如 SQL Server 中：
REPLACE(REPLACE(RTRIM(LTRIM(col)), CHAR(13), ''), CHAR(10), '')
在 WHERE 条件里用 LTRIM()/RTRIM() 会失效索引
写 WHERE LTRIM(name) = 'Alice' 会导致全表扫描——数据库无法利用 name 字段上的索引。更糟的是，RTRIM(LTRIM(name)) 嵌套后同样失效。
可行替代方案有：
- 提前清洗：执行
UPDATE t SET name = RTRIM(LTRIM(name))，再建索引 - 用模糊匹配兜底：
WHERE name LIKE 'Alice' OR name LIKE 'Alice %' OR name LIKE '% Alice'（需配合LENGTH()控制长度范围） - MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_ltrim_name ON t (LTRIM(name))，但仅对该函数形式生效
跨数据库兼容性最强的写法就是 RTRIM(LTRIM(col))
它能在 SQL Server 2005+、MySQL 5.6、PostgreSQL、Oracle、SQLite 全部跑通。虽然不如 TRIM(col) 简洁，但胜在稳定。唯一要注意的是：
- 别写成
LTRIM(RTRIM(col))—— 效果一样，但可读性略差 - 如果字段本身参与计算（如
UPPER(col)），嵌套后变成UPPER(RTRIM(LTRIM(col)))，括号容易漏 - ORM（如 Django 的
.extra(where=[...])）可能把RTRIM(LTRIM(...))当作字面量拼接，需确认驱动是否转义
真正麻烦的从来不是语法，而是你不知道原始字符串里到底混进了几个不可见字符。
