LPAD函数用于左填充字符串，参数依次为str、len、padstr；需显式转换数字为字符并处理NULL和负号，否则补零失败或结果异常。
LPAD函数的基本用法和参数含义
LPAD 是 MySQL 中用于左填充字符串的函数，它不会自动把数字转成字符串再补零——这点必须手动处理，否则会出错。它的三个参数依次是：str（原始值）、len（目标总长度）、padstr（填充字符）。如果 str 是数字类型（比如 INT），MySQL 会隐式转成字符串，但隐式转换可能丢失前导零逻辑，尤其当原始值为空或为 NULL 时。
常见错误现象：SELECT LPAD(5, 4, '0') 返回 '0005' 看似正常，但 SELECT LPAD(id, 4, '0') FROM table WHERE id = 0 可能返回 '0000' 或空字符串，取决于字段是否允许 NULL 和实际存储值。
- 必须确保输入值非
NULL，否则LPAD返回NULL -
len小于原字符串长度时，结果会被截断（不是报错） - 数字字段建议先用
CAST(... AS CHAR)显式转类型，避免隐式行为差异
处理含NULL或负数的数字字段
直接对可能为 NULL 的数字字段用 LPAD，会导致整行结果变 NULL。负号也会干扰补零逻辑：例如 LPAD(-7, 3, '0') 得到 '-07'，而非预期的 '007'。
推荐写法是先用 IFNULL 或 COALESCE 处理空值，再用 ABS 去掉负号，最后显式转字符串：
SELECT LPAD(CAST(IFNULL(ABS(num_field), 0) AS CHAR), 6, '0') FROM t;
-
ABS()避免负号占位导致补零失败 -
CAST(... AS CHAR)比隐式转换更可控，尤其在严格 SQL 模式下 - 如果业务上不允许负数，应在应用层或 CHECK 约束中拦截，而不是靠
LPAD修复
在UPDATE语句中安全地补零并写回字段
想把补齐后的结果存回原字段？小心字段类型。如果原字段是 INT，无论你怎么 LPAD，存进去的仍是数值，前导零会立刻消失。只有 CHAR、VARCHAR 类型才能保留补零结果。
执行前务必确认目标字段类型：
SHOW COLUMNS FROM t LIKE 'code';
- 若字段是
INT，改字段类型：ALTER TABLE t MODIFY code VARCHAR(10); - UPDATE 时加条件避免覆盖有效数据：
UPDATE t SET code = LPAD(CAST(id AS CHAR), 5, '0') WHERE LENGTH(CAST(id AS CHAR)) - 注意
WHERE条件里不能用LPAD，否则无法使用索引，大数据量时很慢
性能与字符集影响
LPAD 是逐行计算函数，没有索引加速。在百万级表上直接 SELECT LPAD(...) 不会影响查询计划，但若用于 WHERE 或 ORDER BY，会导致全表扫描。
另一个容易被忽略的点：多字节字符集（如 utf8mb4）下，LPAD 的 len 参数按字符数计，不是字节数。所以 LPAD('€', 3, '0') 结果是 '00€'，而非 '00€' 占三字节那种误解。
复杂点在于：如果你的字段内容本身含 emoji 或中文，又混用补零逻辑（比如编码前缀+数字），LPAD 依然只看字符个数，不区分语义。这种场景建议在应用层处理，数据库只存原始数值。
