LPAD在左侧填充、RPAD在右侧填充，二者方向相反；均以目标总长度len为准，若原字符串超长则截断前n位，空值返回NULL，多字节字符需注意字节与字符长度差异。
LPAD 和 RPAD 的基本行为差异
LPAD 和 RPAD 都是字符串填充函数，但方向相反：LPAD 在左侧补字符，RPAD 在右侧补。它们在 MySQL、PostgreSQL、Oracle 中都支持，但 SQLite 默认不支持（需自定义或换用 printf）。注意：SQL Server 没有原生 LPAD/RPAD，得用 REPLICATE + RIGHT 或 CONCAT 模拟。
两个函数签名一致：LPAD(str, len, pad_str)，其中：
- str 是待处理的原始字符串
- len 是目标总长度（不是补多少个字符）
- pad_str 是填充用的字符串，会被截断或重复使用
常见错误是把 len 误当成“补几个字符”，结果导致意外截断。例如 LPAD('123', 2, '0') 返回 '12'（不是报错），因为目标长度 2 小于原串长度，函数直接截取前 2 位。
补齐编码时如何避免截断和空值问题
业务中常用来生成固定位数编号（如订单号 'ORD000123'），这时必须确保原始值不为空、且长度可控。否则 LPAD(NULL, 8, '0') 结果仍是 NULL，而 LPAD('', 8, '0') 会返回 8 个 '0' —— 这往往不是你想要的。
- 用
COALESCE或IFNULL（MySQL）兜底空值：LPAD(COALESCE(order_id, '0'), 6, '0') - 对可能超长的字段先
SUBSTR截断，再填充，避免意外溢出：LPAD(SUBSTR(raw_code, 1, 5), 5, 'X') - 若原始字段是数字类型（如
INT），务必显式转字符串：LPAD(CAST(id AS CHAR), 6, '0')，否则某些数据库（如 MySQL 8.0+）会隐式转成带空格的右对齐字符串，填充结果错乱
不同数据库对 pad_str 的处理差异
pad_str 参数看似简单，实则最容易踩坑。它的行为在各数据库中不完全一致：
- MySQL：若
pad_str为空字符串（''），LPAD直接返回NULL - PostgreSQL：空字符串被视作无填充，返回原字符串（不报错也不截断）
- Oracle：允许空字符串，但填充逻辑按字节而非字符，多字节字符（如中文）可能导致总长度计算偏差
- 所有数据库：当
pad_str长度大于所需填充量时，只取左侧部分；例如LPAD('abc', 5, 'XY')→'XYabc'（用'XY'填 2 位）
生产环境建议统一用单字符填充（如 '0' 或 ' '），避免跨库迁移时因 pad_str 解析差异引发编码错位。
性能与索引友好性提醒
在 WHERE 条件里对字段用 LPAD（如 WHERE LPAD(id, 6, '0') = '001234'）会导致全表扫描——函数作用于列，索引失效。真要查补齐后的值，应提前在应用层或写入时就存好标准化编码字段（如 code_padded），并为其建索引。
如果只是 SELECT 展示用，LPAD 开销极小；但若在大表聚合或 JOIN 中高频调用，尤其配合子查询，可能触发临时表或文件排序。此时可考虑用更轻量的替代方案，比如 PostgreSQL 的 to_char(num, 'FM000000')（数值型专用，更快更稳）。
最常被忽略的一点：补齐逻辑是否该由数据库承担？多数情况下，它更适合放在应用层或 ETL 流程里做一次性的、确定性的格式化。数据库函数更适合兜底或临时调试。
