LPAD函数用于字符串左填充，需三个参数：原始字符串、目标长度、填充字符；长度小于原串时MySQL截断而PostgreSQL不截断，数字需先转字符串再使用。
LPAD函数的基本用法和参数含义
LPAD 是多数主流数据库（如 PostgreSQL、Oracle、MySQL 8.0+）支持的字符串左填充函数，用于在字符串左侧补足指定字符至目标长度。它有三个必需参数：string（原始字符串）、length（目标总长度）、fill_char（填充字符）。如果原始字符串已超过目标长度，多数数据库会直接截断（PostgreSQL 不截断，MySQL 截断），这点必须提前确认。
常见错误是把 length 设为小于原字符串长度的值，结果得不到补零效果，甚至意外丢失数据。例如：LPAD('123', 2, '0') 在 MySQL 中返回 '12'，而非 '123' —— 这不是 bug，是设计行为。
- 确保
length大于等于原始值最大可能位数（比如流水号最多 6 位，就设为 6） - 填充字符必须是单字符；传入
'00'会导致报错或静默截为'0' - 原始值若为
NULL，多数数据库返回NULL，需用COALESCE或IFNULL预处理
在自增ID基础上生成固定宽度流水号
典型场景：用表的自增主键 id 生成类似 '000123' 的流水号。不能直接对 id 调用 LPAD，因为 id 是数字类型，而 LPAD 第一个参数要求是字符串。
必须显式转类型。MySQL 和 PostgreSQL 都支持 CAST(id AS CHAR) 或简写 CONVERT(id, CHAR)（MySQL）/ id::TEXT（PostgreSQL）。漏掉这步会报错或触发隐式转换异常（尤其在严格 SQL 模式下）。
示例（MySQL）：
SELECT LPAD(CAST(id AS CHAR), 6, '0') AS serial_no FROM orders ORDER BY id DESC LIMIT 5;
- 避免写成
LPAD(id, 6, '0')—— 数字直接传入在某些版本会失败或结果不可控 - 如果业务要求流水号按“年份+序号”组合（如
'2024000123'），先拼接再LPAD，但注意拼接后总长要重新计算 - 不要在 WHERE 或 JOIN 条件中对
LPAD结果做等值匹配——无法走索引，性能极差
不同数据库对 LPAD 的兼容性差异
SQLite 和旧版 MySQL（LPAD。强行使用会报错：FUNCTION xxx.LPAD does not exist。这不是语法问题，是功能缺失。
替代方案需手动构造：
- MySQL 5.7–：用
REPEAT('0', 6 - LENGTH(id))拼接，但需先CAST且处理LENGTH为负数的情况（加GREATEST(0, ...)） - SQLite：无内置
LPAD，常用SUBSTR('000000' || id, -6)实现，前提是知道最大位数且id不超长 - SQL Server：没有
LPAD，改用RIGHT('000000' + CAST(id AS VARCHAR), 6)
跨库迁移时，别只测试正向逻辑，务必验证边界值（如 id = 0、id = 1000000）是否溢出或报错。
在 INSERT 语句中实时生成补零流水号的风险
有人试图在 INSERT 里用 LPAD 直接写入格式化后的值（如 INSERT INTO logs(serial) VALUES (LPAD(@next_id, 6, '0'))），这是危险操作。
问题在于：流水号本质是显示格式，不是业务主键。把它当字段存，会导致后续排序、分页、范围查询全部依赖字符串比较（'000100' > '00099' 成立，但数值上 100
- 正确做法是单独存原始数字（如
seq_no INT），展示层或视图里用LPAD格式化 - 若真要存格式化值，必须加唯一约束并确保生成逻辑绝对原子（比如用序列+函数封装，而非客户端算好再插）
- 高并发下靠
MAX()+1手动算下一个号 +LPAD，大概率重复或跳号，应交给数据库序列或自增机制
补零只是视觉对齐，背后的数据模型和生成时机比函数本身更关键。很多人调通了 LPAD 就以为完成了，其实刚踩到第一个坑。
