用TRIM最稳妥，它默认去首尾空格、语法统一；老版本需指定BOTH/LEADING/TRAILING或改用RTRIM(LTRIM(col))；注意空白字符兼容性及WHERE中TRIM导致索引失效问题。
SQL里去掉首尾空格，用TRIM最稳妥
绝大多数现代数据库（PostgreSQL、SQL Server 2017+、MySQL 8.0+、Oracle）都支持标准TRIM函数，语法统一、语义清晰。它默认就是去首尾空格，不用记方向，也不用拼两个函数。
常见错误是硬套旧习惯：比如在MySQL 5.7里写TRIM(' abc ')——这会报错，因为老版本TRIM必须带BOTH/LEADING/TRAILING关键字；而LTRIM/RTRIM又容易漏掉一边。
-
TRIM(' hello ')→ 在PostgreSQL/Oracle/SQL Server中直接生效；MySQL 8.0+也支持 - MySQL 5.7或更早：必须写成
TRIM(BOTH ' ' FROM ' hello ') - 如果字段可能含制表符、换行符，
TRIM默认只处理空格，得显式指定：TRIM(BOTH FROM '\t\n hello \r\n\t')（各库对非空格字符的支持程度不一）
兼容老版本数据库时，LTRIM和RTRIM要配对用
SQL Server和旧版MySQL依赖LTRIM和RTRIM，但它们只单向生效——单独用任何一个，都只能解决一半问题。线上出过不少bug，就是因为只写了LTRIM(col)，结果尾部空格还在，导致=匹配失败。
- 安全写法永远是嵌套：
RTRIM(LTRIM(col))，顺序无所谓，但不能省一个 - SQL Server里
RTRIM(LTRIM(N' hello '))（全角空格）无效——LTRIM/RTRIM只认ASCII空格（0x20），不处理Unicode空白符 - 某些ODBC驱动或ORM（如旧版Django ORM）生成的SQL会自动加
RTRIM，但仅限CHAR类型字段，VARCHAR不受影响，这点容易被忽略
WHERE条件里用TRIM可能让索引失效
在WHERE子句里对字段调用TRIM(col)，基本等于放弃索引。数据库没法用B-Tree索引快速定位“去掉空格后等于X”的值，只能全表扫描。
- 真正要查干净数据，应该在写入时就清洗：
INSERT INTO t (name) VALUES (TRIM(?)) - 如果必须查，且字段空格是偶发的，优先考虑加计算列+索引（如SQL Server的
name_trim AS TRIM(name)+ 索引） - MySQL 8.0+支持函数索引：
CREATE INDEX idx_name_trim ON t ((TRIM(name)))，但要注意表达式必须完全一致，WHERE TRIM(name) = 'abc'才能命中
不同数据库对空白字符的定义其实不一致
TRIM在标准SQL里只针对空格（U+0020），但实际业务里常遇到制表符、全角空格、零宽空格甚至换行符。各数据库默认行为差异很大，不能假设“trim完就真干净了”。
- PostgreSQL的
TRIM严格遵循标准，只处理空格；想清空所有Unicode空白，得用正则：REGEXP_REPLACE(col, '^\s+|\s+$', '') - Oracle的
TRIM默认也只认空格，但TRIM(CHR(9) FROM col)可以手动指定制表符（CHR(9)） - SQL Server的
TRIM（2017+）已扩展支持Unicode空白，TRIM(N' \thello\r\n')能同时干掉全角空格、制表符、回车和换行
真正麻烦的是混合场景：比如从Excel导入的数据，可能夹着\r\n和全角空格，而你的SQL只写了TRIM——看起来没报错，但比对总失败。这种细节，光看文档不够，得拿真实脏数据试。
