RTRIM默认只删除ASCII空格（U+0020），不处理制表符、换行符、回车符及全角空格等Unicode空白字符；MySQL 8.0+/PostgreSQL支持RTRIM(col, ' \t\n\r')显式指定字符集，SQL Server仅支持单字符修剪。
SQL RTRIM 函数到底删哪些字符
RTRIM 默认只删除 ASCII 空格（U+0020），不处理制表符 \t、换行符 \n、回车符 \r，也不删 Unicode 空白字符（如 、全角空格、零宽空格）。很多用户发现“明明看着是空的，RTRIM 却没删掉”，大概率是碰上了这些隐形字符。
常见错误现象：RTRIM('abc ')（末尾是全角空格）返回结果仍是 'abc '；RTRIM('abc' + CHAR(9))（带制表符）也原样保留。
- MySQL 8.0+ 和 PostgreSQL 支持多字符参数：
RTRIM(col, ' \t\n\r')可显式指定要删的字符集 - SQL Server 仅支持单字符修剪，必须用
REPLACE嵌套或TRIM（2017+）替代 - SQLite 的
RTRIM同样只认空格，且不支持第二个参数
什么时候该用 RTRIM 而不是 TRIM
如果你明确只需要清理右侧空白，RTRIM 比 TRIM 更安全——它不会意外去掉左侧本应保留的内容，比如编号前缀 '00123 ' 或路径开头的斜杠 '/path/to/ '。
但要注意：标准 SQL 中 TRIM(TRAILING FROM col) 功能等价于 RTRIM(col)，而多数数据库（PostgreSQL、SQL Server）已将 TRIM 作为推荐写法。MySQL 5.7 之前没有 TRIM 多参数支持，所以老项目里仍常见 RTRIM。
- 兼容旧系统或跨数据库脚本时，优先用
RTRIM（语义清晰、支持广） - 新项目且确认数据库版本 ≥ 2017（SQL Server）或 ≥ 8.0（MySQL），直接用
TRIM(TRAILING FROM col)更规范 - 别在 WHERE 条件里对字段用
RTRIM做匹配（如WHERE RTRIM(name) = 'Alice'），会无法走索引
RTRIM 在 UPDATE 语句中容易踩的坑
批量更新时直接写 UPDATE t SET name = RTRIM(name) 看似简单，但可能触发意料外的行为：
- 如果字段是
CHAR(10)类型，SQL Server/MySQL 会自动补空格到长度 10，RTRIM后再存回去仍会被填充——实际没变 - 某些 ORM（如 SQLAlchemy）对
CHAR字段默认启用 blank-padded 比较，导致WHERE name = 'abc'匹配到'abc '，但RTRIM更新后反而破坏这种隐式兼容 - 没加
WHERE条件就全表更新，可能把原本就干净的数据反复处理，增加日志体积和锁等待
稳妥做法：UPDATE t SET name = RTRIM(name) WHERE name != RTRIM(name)（注意 NULL 需单独判断）。
字符串末尾有多个空格时，RTRIM 是一次性全删还是逐个删
RTRIM 是原子操作：从右往左扫描，遇到第一个非空格字符就停止，所有连续空格一并移除。不存在“循环调用”或性能衰减问题。
示例：RTRIM('hello ')（4 个空格）和 RTRIM('hello ')（1 个空格）执行耗时几乎无差别。真正影响性能的是字段长度和数据量——如果对百万行 TEXT 字段执行 RTRIM，I/O 开销远大于函数本身。
容易被忽略的一点：有些数据库（如 Oracle）的 RTRIM 默认行为受 BLANK_TRIMMING 会话参数影响，但主流开源数据库（PostgreSQL、MySQL）不提供该开关，行为固定。
