必须嵌套使用RTRIM(LTRIM(col))才能清除两端空格，因LTRIM仅去左、RTRIM仅去右，且二者只识别ASCII空格，对制表符、换行符、全角空格等完全无效；单独使用会导致WHERE匹配失败、GROUP BY分组异常、JOIN关联失效及索引失效。
为什么LTRIM()和RTRIM()必须嵌套使用
LTRIM()只删左边空格，RTRIM()只删右边空格，单独用任何一个都留着另一侧的空格。比如字段值是' Alice '，LTRIM(name)结果是'Alice '，RTRIM(name)结果是' Alice'，只有RTRIM(LTRIM(name))或LTRIM(RTRIM(name))才能得到'Alice'。
常见错误写法：WHERE LTRIM(name) = 'Alice'——右侧空格或换行符还在，匹配失败；GROUP BY RTRIM(name)——左侧空格没清，导致分组键不一致。
它们只认ASCII空格，其他“空白”全无效
LTRIM()和RTRIM()只处理字符CHAR(32)（即普通空格），对以下内容完全无感：
- 制表符
CHAR(9) - 换行符
CHAR(10)、回车符CHAR(13) - 不间断空格
CHAR(160)、全角空格NCHAR(12288)
验证方法：SELECT name, CAST(name AS VARBINARY(MAX)) FROM t WHERE id = 1，看末尾字节是不是0D0A（CR+LF）或A0（NBSP）。若存在，需叠加REPLACE()，例如：REPLACE(REPLACE(RTRIM(LTRIM(col)), CHAR(13), ''), CHAR(10), '')。
在WHERE里直接用会触发全表扫描
写WHERE RTRIM(LTRIM(name)) = 'John'，哪怕name字段上有索引，数据库也无法利用——函数作用于列后，B-Tree索引结构失效，必然走全表扫描。
可行方案有两类：
- 提前清洗：在
INSERT/UPDATE时就执行SET name = RTRIM(LTRIM(name))，并确保业务层不写入带空格的值 - 建计算列索引（SQL Server 2016+）：
ALTER TABLE t ADD name_clean AS RTRIM(LTRIM(name)); CREATE INDEX IX_name_clean ON t(name_clean);，之后查WHERE name_clean = 'John'就能走索引
旧版SQL Server必须用嵌套，TRIM()不是万能钥匙
SQL Server 2016及更早版本根本不认识TRIM()函数，执行会报错Invalid column name 'TRIM'；2017+才支持，但语法强制为TRIM(' ' FROM col)，写成TRIM(col)仍报错。
所以跨版本兼容的写法只有一个：RTRIM(LTRIM(col))。它在SQL Server 2005起全部支持，MySQL、PostgreSQL、Oracle也都能跑通——但注意，Oracle的TRIM()从12c才支持标准语法，之前也得靠RTRIM(LTRIM())。
真正麻烦的从来不是怎么写函数，而是数据里混着哪些看不见的字符，以及你是否在查询前就意识到索引已经废了。
