RPAD函数在字符串右侧填充指定字符至目标长度，若源串长度超长则截断左侧部分；常见错误包括误用截断逻辑、忽略NULL处理、字符集与字节长度混淆及跨库兼容性问题。
RPAD 函数的基本用法和常见错误
RPAD 用来在字符串右侧填充指定字符，直到达到目标长度。它接受三个参数：RPAD(str, len, padstr)。如果 str 原长已 ≥ len，MySQL 和 Oracle 会直接截断（注意：PostgreSQL 不支持截断，只返回原字符串）。常见错误是误以为 RPAD 总是“补足”，结果字段反而被意外截短，尤其在处理中文或宽字符时——因为 len 是按字符数计，不是字节数。
- MySQL 中
RPAD('你好', 5, 'x')返回'你好xxx'（共 5 个字符） - 但
RPAD('hello world', 5, '0')返回'hello'（原串超长，直接截断前 5 字符） - Oracle 行为一致；PostgreSQL 则报错或忽略截断逻辑，需显式用
SUBSTR配合
生成定长字段时必须处理的边界场景
定长字段常用于导出固定格式文件（如银行报文、EDI），此时空格/零填充必须严格可控。最容易漏掉的是空值（NULL）和空字符串（''）的处理——RPAD(NULL, 10, '0') 结果仍是 NULL，而 RPAD('', 10, '0') 得到 '0000000000'，二者语义完全不同。
- 统一空值：用
COALESCE(col, '')或IFNULL(col, '')（MySQL）提前转为空字符串 - 避免多余空格：若源字段含尾部空格，先
RTRIM(col)再RPAD，否则填充后长度可能超标 - 确认字符集：UTF8MB4 下一个 emoji 占 4 字节但算 1 字符，
len=10不代表 10 字节宽
不同数据库的兼容写法差异
SQL 标准不强制要求 RPAD，各数据库实现有细微差别。MySQL 和 Oracle 支持三参数且截断；PostgreSQL 的 RPAD 不截断，要模拟相同行为得组合使用：
SELECT LPAD(RPAD(COALESCE(col, ''), 10), 10, '0') FROM t;
更稳妥的做法是用条件判断：
SELECT CASE WHEN LENGTH(COALESCE(col, '')) >= 10 THEN LEFT(COALESCE(col, ''), 10) ELSE RPAD(COALESCE(col, ''), 10, '0') END FROM t;
- MySQL 可直接写
RPAD(IFNULL(col, ''), 10, '0') - SQL Server 没
RPAD，改用LEFT(col + REPLICATE('0', 10), 10)，但要注意col为NULL时整个表达式变NULL - SQLite 从 3.42+ 才支持
RPAD，旧版只能拼接 +SUBSTR
性能与索引注意事项
在 WHERE 或 JOIN 条件里用 RPAD(col, 10, ' ') 会导致索引失效，因为函数改变了列值。如果只是为展示或导出做格式化，务必放在 SELECT 列表里，而不是过滤条件中。
- 需要按“定长形式”查询时，应预先计算并存入冗余字段（如
code_padded），再对其建索引 -
RPAD本身开销小，但若对百万行执行，且padstr是多字符（如'AB'），填充逻辑会稍慢于单字符 - 导出场景下，优先考虑应用层处理：数据库只提供原始数据，由 Python/Java 控制填充逻辑，更灵活也避免 SQL 复杂度
真正麻烦的是混合中英文+符号的定长需求——一个汉字、一个英文字母、一个全角破折号，在不同排序规则下可能被算作不同“字符长度”，这时光靠 RPAD 不够，得结合具体业务规则做预处理。
