LPAD函数用于字符串左填充，语法为LPAD(str, len, padstr)，参数分别为原字符串、目标长度和填充字符；若原长≥len则截断，不报错；需注意数据库间隐式转换差异及空格等干扰因素。
LPAD 函数的基本用法和参数含义
LPAD 是多数主流数据库（如 PostgreSQL、Oracle、MySQL 8.0+）支持的字符串左填充函数，作用是把一个字符串补足到指定长度，不足部分用指定字符从左侧填充。它接受三个参数：string（原字符串）、length（目标总长度）、fill（填充字符）。注意：如果 string 原长已超过 length，结果会被截断（不是报错），这点容易被忽略。
常见误用是直接对数字字段调用 LPAD，比如 LPAD(id, 6, '0') —— 如果 id 是整数类型，某些数据库（如 PostgreSQL）会拒绝执行，必须先转成字符串；MySQL 则隐式转换，但行为不一致，建议统一显式转换。
- PostgreSQL 必须写成
LPAD(id::text, 6, '0') - MySQL 可用
LPAD(CAST(id AS CHAR), 6, '0')或LPAD(id + '', 6, '0')（后者依赖隐式转换，不推荐） - Oracle 中
TO_CHAR(id, 'FM000000')是更惯用的替代方案，但LPAD同样可用：LPAD(id, 6, '0')
补零编号时常见的错误现象
最典型的问题是补出来的结果长度不对，比如期望 6 位却得到 5 位或 7 位。这通常由三类原因导致：
-
length参数设小了：例如原编号最大是99999（5 位），设LPAD(..., 5, '0')，那1会变成'00001'，但100000就直接被截成'00000'—— 数据出错 - 字段含空格或不可见字符：如
' 123 '被当成 5 字符处理，LPAD会先填充再截断，结果混乱 - 排序异常：补零后得到字符串，
ORDER BY默认按字典序排，'10'会排在'2'前面 —— 若需数值顺序，得额外用CAST(... AS INTEGER)或保持原始字段排序
不同数据库中 LPAD 的兼容性差异
SQLite 和旧版 MySQL（LPAD，强行使用会报错 no such function: LPAD。这时不能硬套语法，得换方案：
- MySQL 5.7 及更早：用
LPAD的等效写法是RIGHT(CONCAT(REPEAT('0', 6), id), 6)，但要注意id必须是字符串上下文 - SQLite：没有内置
LPAD，常用组合是SUBSTR('000000' || id, -6)（假设固定补到 6 位），但要确保id不含负号或小数点 - SQL Server：没有
LPAD，对应的是RIGHT(REPLICATE('0', 6) + CAST(id AS VARCHAR), 6)
跨数据库项目里，如果只靠 LPAD 写通用 SQL，大概率在某个环境跑不起来。
实际业务中该不该用 LPAD 补零？
补零编号常用于单据号、设备编码等场景，但直接在 SQL 查询里用 LPAD 生成，往往掩盖了更本质的问题：
- 展示层补零更合理：比如应用代码或报表工具里格式化，避免数据库层做无谓字符串操作
- 存储时就该定长：如果编号规则固定为 6 位，建表时就该用
CHAR(6)并约束值域，比每次查都LPAD更高效 - 自增 ID 不适合补零：比如主键
id=1补成'000001'，一旦后期要改位数（如升到 8 位），所有历史数据展示逻辑都要动
真正需要 LPAD 的，通常是临时拼接、导出报表、对接老系统这类明确要求字符串格式的场合。其他时候，优先考虑字段设计和应用层处理。
