lpad函数用于左填充字符串至指定长度，语法为lpad(str, len, padstr)，其中str为原字符串，len为目标总长度（超长则截断），padstr为填充字符（仅首字符有效）。
LPAD函数的基本用法和参数含义
LPAD 是 MySQL 中用于左填充的字符串函数，核心作用是把一个原始字符串用指定字符补足到目标长度。它接收三个参数：str（待处理字符串）、len（目标总长度）、padstr（填充字符）。当 str 长度已大于等于 len 时，MySQL 会直接截断返回前 len 个字符，这点容易被忽略，导致流水号意外截短。
常见错误现象：用 LPAD(id, 6, '0') 处理 id = 1234567，结果得到 '123456' 而非预期的 '1234567' —— 因为长度超了就被截断，不是报错或忽略。
- 填充字符
padstr只取第一个字符，LPAD('5', 4, '00')和LPAD('5', 4, '0')效果一样 -
len必须是非负整数，传负数或 NULL 会导致返回 NULL - 如果原始值是数字类型（如
INT），MySQL 会隐式转成字符串再填充，但要注意隐式转换可能丢失前导空格或触发科学计数法（极大数据）
生成流水号时如何避免自增ID断层导致的位数混乱
直接对 AUTO_INCREMENT 字段用 LPAD(id, 6, '0') 看似简单，但实际业务中删除、回滚、跳号都会让 id 不连续，进而导致流水号位数不一致（比如出现 '00012' 和 '001234' 混用）。更稳妥的做法是用独立的流水号生成逻辑，不依赖物理主键。
推荐方案：用 MAX() + LPAD 在事务中安全递增：
START TRANSACTION;
SELECT LPAD(IFNULL(MAX(seq_no), 0) + 1, 6, '0') AS next_no FROM orders FOR UPDATE;
-- 应用层拿到 next_no 后插入新记录
INSERT INTO orders (seq_no, ...) VALUES ('000123', ...);
COMMIT;
- 必须加
FOR UPDATE，否则并发插入可能生成重复流水号 - 不能只靠
LPAD(id, 6, '0')，因为id是主键，而流水号通常需独立于主键存在（例如导出报表时要求严格6位） - 如果表数据量极大，
MAX()全表扫描会影响性能，此时应考虑用单独的序列表或 Redis 计数器
与ZEROFILL、FORMAT等其他补零方式的区别
ZEROFILL 是列定义属性，仅影响显示，底层存储仍是原数值；FORMAT() 会添加千分位逗号且返回字符串，不适合纯数字流水号。三者行为差异明显：
-
INT(6) ZEROFILL：建表时指定，插入42显示为'000042'，但 SELECT 返回仍是数字类型，参与计算时自动转回42，无法保证固定字符串输出 -
FORMAT(42, 0)返回'42'，但FORMAT(1234, 0)返回'1,234'—— 多了个逗号，不能用 -
LPAD(CAST(42 AS CHAR), 6, '0')始终返回'000042'字符串，可控、无副作用，适合拼接或导出
注意：如果字段本身是 VARCHAR 或 CHAR，直接 LPAD(col, 6, '0') 即可；若是数值型，显式用 CAST(col AS CHAR) 更安全，避免某些 MySQL 版本隐式转换异常。
在INSERT语句中直接生成流水号的写法
想在插入时就生成并存入，可用子查询或变量，但要注意语法限制。最简可靠写法是用子查询获取当前最大值后加一：
INSERT INTO orders (seq_no, order_time) SELECT LPAD(IFNULL(MAX(seq_no), 0) + 1, 6, '0'), NOW() FROM orders;
这个语句在单次插入时有效，但并发下仍需事务包裹。若需批量插入多条且每条都不同流水号，LPAD 就不适用了——它没法自动递增，得配合变量或应用层生成。
- 不要写
LPAD(@row := @row + 1, 6, '0')这类用户变量用法，MySQL 8.0+ 已明确不保证执行顺序，极易出错 - 避免在 INSERT ... SELECT 中对同一张表做聚合再插入（如上例），某些旧版本会报错
ERROR 1093，此时需套一层派生表 - 生产环境建议把流水号生成逻辑封装进存储过程，统一处理事务、重试和异常
真正麻烦的不是 LPAD 本身，而是怎么让它在高并发、可回滚、可审计的前提下稳定产出不重复、定长、无间隙的字符串——函数只是工具，背后的数据一致性策略才是关键。
