MySQL用LPAD(id,6,'0')、PostgreSQL用TO_CHAR(id,'FM000000')、SQL Server用RIGHT(REPLICATE('0',6)+CAST(id AS VARCHAR),6)实现数字前导零补齐，均需避免在WHERE中使用以防索引失效。
MySQL 中用 LPAD 实现数字字段前导零补齐
直接用 LPAD() 是最稳妥的方式，它不依赖字段类型，也不改变原始数据，只在查询时格式化输出。比如要把 id 字段统一显示为 6 位（不足补 0），写法是：LPAD(id, 6, '0')。注意第二个参数是目标总长度，第三个是填充字符，必须是字符串。
常见错误是传入负数或小数给长度参数，MySQL 会报错 Invalid argument for function lpad；另外如果原始值本身转成字符串后长度超过指定长度（比如 id = 1234567 要 LPAD(..., 6, ...)），LPAD 会原样返回完整字符串，不会截断——这点容易被误以为“没生效”。
使用场景包括生成编号、对齐报表输出、对接需要固定长度字符串的外部系统。如果字段是 INT 类型，LPAD 会自动隐式转换为字符串；但如果是 DECIMAL 或带小数的值，建议先用 CAST(id AS UNSIGNED) 或 FLOOR(id) 处理，避免小数点干扰补零逻辑。
PostgreSQL 中用 TO_CHAR 格式化数字补零
PostgreSQL 没有 LPAD 的直接等价函数处理数字补零，推荐用 TO_CHAR() 配合格式模型，例如：TO_CHAR(id, 'FM000000') 表示 6 位数字，FM 去掉前导空格，0 表示必须显示的数字位（不足补 0）。
容易踩的坑：如果 id 是 NULL，TO_CHAR 返回空字符串，不是 NULL，业务上可能需要额外 COALESCE(TO_CHAR(id, 'FM000000'), '000000') 处理；另外格式串里不能混用 9 和 0——9 表示“可选位”，遇到 0 值会变为空格，而 0 才强制补零。
性能方面，TO_CHAR 是标量函数，对大结果集无明显开销；但如果在 WHERE 或 JOIN 条件里用它做匹配（比如 TO_CHAR(id, 'FM000000') = '000123'），就无法走索引，应避免。
SQL Server 中用 RIGHT + REPLICATE 组合补零
SQL Server 没有内置数字补零函数，惯用写法是：RIGHT(REPLICATE('0', 6) + CAST(id AS VARCHAR), 6)。先拼接足够多的 0，再取右 6 位，确保长度恒定。
这个写法在 id 为负数时会出问题（比如 -5 变成 '0000-5'），所以生产环境务必加判断：CASE WHEN id 。
另一个常见疏漏是没考虑 id 超长的情况：如果 id = 12345678，上述表达式仍返回 6 位，但实际是后 6 位 '345678'——这属于截断而非补零，和预期不符。如需严格保证“超长则报错或标记”，得配合 LEN(CAST(id AS VARCHAR)) > 6 做校验分支。
通用提醒：别在 WHERE 条件里对数字字段做字符串补零操作
所有数据库都一样：把 LPAD(id, 6, '0') 或 TO_CHAR(id, 'FM000000') 放在 WHERE 子句里匹配字符串值，等于放弃索引，全表扫描不可避免。真正要查“编号为 000123 的记录”，应该查原始数字值 WHERE id = 123，而不是查格式化后的字符串。
如果业务确实需要按补零后的字符串检索（比如导入文件里的编号列全是 6 位字符串），正确做法是建一个计算列并持久化索引，例如 MySQL：ALTER TABLE t ADD COLUMN id_code VARCHAR(6) STORED AS (LPAD(id, 6, '0')) INDEX；SQL Server 则用 PERSISTED 计算列。否则每次查询都是实时计算，代价随数据量线性增长。
