LPAD函数用于MySQL中左填充字符串，语法为LPAD(str, len, padstr)，其中str为原始值（自动转字符串）、len为目标总长度、padstr为填充字符；若str长度≥len则原样返回，否则左侧补padstr至指定长度。
LPAD函数的基本用法和参数含义
LPAD 是 MySQL 提供的字符串左填充函数，它不关心输入是否为数字——传进去什么类型，MySQL 会先隐式转成字符串再处理。所以 LPAD(123, 5, '0') 实际上等价于 LPAD('123', 5, '0')，结果是 '00123'。
三个参数缺一不可：
- 第一个参数：要填充的原始值（可以是数字、字符串或列名）
- 第二个参数：目标总长度（不是补几个零，而是最终字符串长度）
- 第三个参数：填充字符（必须是字符串，单字符最安全；多字符如
'0x'会导致循环填充）
数字转字符串时隐式转换可能出问题
直接对整数列用 LPAD 看似简单，但要注意浮点数或带小数点的值会被截断或科学计数法干扰。比如 LPAD(12.34, 5, '0') 结果是 '12.34'（长度已够），而 LPAD(12345678901234567890, 20, '0') 可能因精度丢失变成 '01234567890123456789'（末位不准）。
更稳妥的做法是先显式转字符串：
SELECT LPAD(CAST(id AS CHAR), 6, '0') FROM orders;
尤其当字段是 BIGINT 或含负号时，CAST(... AS CHAR) 能避免符号被忽略或格式错乱。
常见错误：补零后排序失效
补零后的结果是字符串，按字典序排序：'009' > '010' 是错的（因为 '0' '1'，但 '009' 字符串比 '010' 小）。如果后续要用这个字段做范围查询或 ORDER BY，容易出逻辑 bug。
真正需要“格式化显示”时，应该：
- 只在 SELECT 层做
LPAD，不影响存储和索引 - 不要把
LPAD结果存入新字段（除非业务明确要求字符串存储） - 排序仍用原始数值字段，例如：
ORDER BY id，而不是ORDER BY LPAD(id, 6, '0')
替代方案：用 FORMAT 或自定义函数？
FORMAT 函数不适合补零——它加千分位和四舍五入，比如 FORMAT(5, 6) 得到 '5.00000'，还带小数点。
如果补零逻辑复杂（如动态长度、条件判断），建议封装成存储函数，但要注意：
- 函数内不能用
LPAD处理 NULL 值——结果直接为 NULL，需提前IFNULL或COALESCE - 性能敏感场景慎用函数，
LPAD本身很快，但函数调用有额外开销 - MySQL 8.0+ 支持窗口函数，但
LPAD本身不参与窗口计算，别误套用
补零这事，LPAD 已经足够，关键在理解它只操作字符串、不改变数据语义。别指望它让数字变“有前导零的数字”，那根本不存在——数字没有前导零，只有字符串才有。
