LPAD是MySQL左填充函数，语法为LPAD(str, len, padstr)，用于生成固定长度字符串；当原字符串长度≥len时直接返回原串，不截断；len须为非负整数，padstr需为字符串，常用于订单号等前导零编号。
LPAD函数的基本用法和参数含义
LPAD 是 MySQL 中用于左填充字符串的函数，常用来生成固定长度的编号（比如订单号、工单号）。它的签名是 LPAD(str, len, padstr)：第一个参数是要处理的原始字符串，第二个是目标总长度，第三个是用于填充的字符（可重复）。
关键点在于：如果原始字符串长度已 ≥ len，LPAD 不会截断，而是原样返回；它只负责“补”，不负责“裁”。所以生成序列号前，必须确保输入值本身不会超长。
- 填充字符
padstr只能是字符串，传数字会隐式转成字符串（如0→'0'），但建议显式写'0'避免歧义 -
len必须是非负整数，传负数或 NULL 会导致结果为 NULL - 若原始值是数字（如自增ID），MySQL 会自动转成字符串再填充，但要注意科学计数法风险（如大数字可能变成
'1.23e+8'）
用LPAD生成带前导零的流水号（如 ORD00001）
典型场景是把主键 ID 转成固定 6 位编号，前面补零。假设表 orders 有自增主键 id，想查出格式为 'ORD' + 6位数字 的编号：
SELECT CONCAT('ORD', LPAD(id, 6, '0')) AS order_no FROM orders;
注意这里不能直接对 id 做 LPAD(id, 6, 0) —— 虽然 MySQL 会尝试转，但显式用 '0' 更安全。另外，如果 id 达到 1000000（7 位），LPAD 仍返回完整数字（如 '1000000'），不会报错也不会截断，这容易导致后续业务解析失败。
- 生产环境建议配合
WHERE id < 1000000或用触发器/应用层控制最大 ID 范围 - 如果需要严格限制位数，得额外加
SUBSTR(LPAD(...), -6)，但这是掩耳盗铃——本质是设计容量不足 - 避免在 WHERE 条件中对字段用
LPAD（如WHERE LPAD(id,6,'0') = '000123'），会导致索引失效
LPAD在INSERT时自动生成编号的注意事项
想在插入新记录时直接生成编号并存入字段（比如 sn 字段），不能依赖默认值（MySQL 不支持函数作为列默认值，除时间类），常见做法是用 INSERT ... SELECT 或触发器。
推荐在应用层生成（更可控），但如果坚持在数据库侧做，可用如下方式：
INSERT INTO orders (sn, title)
SELECT CONCAT('ORD', LPAD(COALESCE((SELECT MAX(id) FROM orders), 0) + 1, 6, '0')), 'New Order';
这段语句问题很大：并发插入时 MAX(id) 可能重复，且性能差。真正可靠的做法是先执行 INSERT 获取自增 ID，再用 UPDATE 补充 sn，或用存储过程封装原子操作。
- 不要在触发器里读同一张表的 MAX(id)，可能引发表锁或死锁
-
LPAD本身无事务性，它只是字符串计算，不解决并发编号冲突 - 如果编号需全局唯一且带业务前缀，优先考虑 UUID 或雪花算法，而不是靠
LPAD拼接
和其他补齐方式对比：LPAD vs ZEROFILL vs 应用层格式化
ZEROFILL 是整数类型的显示属性（如 INT(6) ZEROFILL），仅影响 SELECT 输出格式，底层存储仍是数字，且 MySQL 8.0.19+ 已弃用该属性；而 LPAD 返回字符串，可自由组合前缀、支持任意字符填充，灵活性高。
但 LPAD 的代价是每次查询都要计算，无法走索引；而纯数字字段 + 应用层格式化（如 Python 的 f"{id:06d}"）既保持存储效率，又把逻辑收口在代码里，便于统一维护和测试。
- 如果只是前端展示需要补零，别在 SQL 里用
LPAD，交给应用层或前端模板 - 如果编号要进日志、导出文件、被其他系统调用，务必确认对方是否真需要字符串形式的固定长度 —— 有时传数字+元数据说明长度更稳妥
-
LPAD对中文、emoji 等多字节字符也有效，但填充单位是字符而非字节，这点和某些编程语言的 pad 函数不同
LPAD 做序列号，最易忽略的是容量边界和并发安全——它只是个字符串缝合工具，不是编号生成器。 
