lpad函数用于左填充字符串至指定长度，参数为str、len、padstr；若str超长则截断，null输入返回null，需用coalesce处理，且填充字符须用ascii '0'。
LPAD函数的基本用法和参数含义
LPAD 是 MySQL 中用于左填充的字符串函数，核心作用是把一个字符串补足到指定长度，不足部分用指定字符从左边填满。它有三个必需参数：str（原始字符串）、len（目标总长度）、padstr（填充字符）。如果 str 原长已超过 len，MySQL 会直接截断返回前 len 个字符——这点常被忽略，导致流水号意外被砍掉。
常见错误现象：明明设了 LPAD(id, 6, '0')，结果得到 '123' 而不是 '000123'，大概率是 id 字段类型为 INT 且值本身已超 6 位，或字段实际存的是字符串但含空格/换行。
- 确保输入是纯数字字符串：建议先用
TRIM和CAST(... AS CHAR)显式转类型 -
len必须是整数，不能是表达式如LENGTH(col)+2（虽然语法允许，但可读性差、易出错） -
padstr如果长度大于 1（比如'00'），MySQL 只取第一个字符，即等效于'0'
生成固定位数流水号的典型 SQL 写法
假设你要把自增主键 id 补成 6 位流水号（如 1 → '000001'），最简写法是：
SELECT LPAD(id, 6, '0') AS serial_no FROM orders;
但生产环境几乎不会这么裸用。真实场景中，流水号往往基于业务日期+序号组合，例如 '202405200001'。这时要拼接：
SELECT CONCAT(DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(id, 4, '0')) AS serial_no FROM orders;
- 注意
DATE_FORMAT的格式符必须严格匹配，'%Y%m%d'是 8 位，别写成'%y%m%d'（变成 6 位） - 如果
id来自子查询或窗口函数（如ROW_NUMBER()），需确保外层再套一层LPAD，否则类型推导可能失败 - 避免在 WHERE 或 ORDER BY 中直接对
LPAD结果做比较——索引失效，性能陡降
与 ZEROFILL、FORMAT 等替代方案的对比
有人会想到用 INT(6) ZEROFILL，但它只影响显示（且在 MySQL 8.0.19+ 已被弃用），实际存储仍是整数，无法支持字符串前缀；也有人试 FORMAT(id, 0)，但该函数加千分位逗号，完全不适合流水号。
真正可比的是手动拼接：REPEAT('0', 6-LENGTH(id)) + id。但这写法更冗长，且当 id 长度超 6 时会拼出负数个 '0'，结果为空字符串，不如 LPAD 的截断逻辑可控。
-
ZEROFILL不可用于生成列（GENERATED COLUMN），而LPAD可以 -
LPAD在视图或生成列中表现稳定，只要基础字段非 NULL，结果就确定 - 若需兼容 MariaDB，注意其
LPAD对NULL输入返回NULL（与 MySQL 一致），但某些旧版有差异
容易被忽略的 NULL 和字符集陷阱
如果源字段（比如 id）为 NULL，LPAD(NULL, 6, '0') 直接返回 NULL，不会报错也不会变 '000000'。这在生成流水号时极危险——你可能以为漏了数据，其实是某条记录的 ID 没写入。
另一个坑是字符集：若表用 utf8mb4，而填充字符用了中文全角零 '０'（U+FF10），LPAD 仍能执行，但结果混入不可见字符，下游系统解析失败。
- 务必用 ASCII 零：
'0'，别用'０'、'①'或空格 - 对可能为 NULL 的字段，显式处理：
LPAD(COALESCE(id, '0'), 6, '0') - 在生成列定义中使用
LPAD时，字段必须有STORED属性，VIRTUAL列不支持函数依赖非确定性函数（但LPAD是确定性的，放心用）
