MySQL的LPAD/RPAD按字节计数而非字符，utf8mb4下中文易出错；应统一字符集、用CHAR_LENGTH计算或移至应用层处理。
LPAD 和 RPAD 在 MySQL 里怎么填字符串才不踩空格坑
MySQL 的 LPAD 和 RPAD 看似简单，但一用就容易出错：填充后长度不对、中文变乱码、字段被截断。根本原因是它们按「字节」计数，不是按「字符」——尤其在 utf8mb4 下，一个汉字占 3 或 4 字节，而你传的长度参数是按字符想的。
实操建议：
-
LPAD(str, len, padstr)和RPAD(str, len, padstr)的len是目标总字节数，不是字符数；如果str本身含多字节字符，实际填充的字符数会少于预期 - 确保连接和表字符集一致：客户端、连接、表都设为
utf8mb4，否则LPAD('你好', 6, '0')可能只补出 2 个0（因为 `'你好'` 占 6 字节，已满） - 若必须按字符数填充，先用
CHAR_LENGTH()判断原长，再换算：比如要补到 10 个汉字宽，且全为 utf8mb4，则len = 10 * 4（最保险），或改用应用层处理
PostgreSQL 没有 LPAD/RPAD？别急，它叫 lpad/rpad（小写）且行为更靠谱
PostgreSQL 的 lpad 和 rpad 默认按「字符」计数，对中文友好得多，也不依赖当前 encoding 字节规则。但要注意它不支持空字符串作为 padstr，会报错 ERROR: zero-length padding string。
常见错误现象：
- 写成
LPAD（大写）—— PostgreSQL 不认，提示函数不存在 - 用空字符串
''当填充符 —— 直接报错，必须至少一个字符 - 填充符长度 > 1（如
'ab'）—— 它会循环截取，rpad('x', 5, 'ab')得到'xabab'，不是重复整个串
SQL Server 用 RIGHT/LEFT + REPLICATE 模拟 LPAD/RPAD，但得防 NULL 和截断
SQL Server 原生没 LPAD/RPAD，常用 RIGHT + REPLICATE 组合实现左补，比如左补 0 到 6 位：RIGHT(REPLICATE('0', 6) + ISNULL(@val, ''), 6)。这里藏着三个易漏点。
实操建议：
- 必须用
ISNULL(@val, '')或COALESCE(@val, '')，否则遇到NULL整个结果变NULL -
REPLICATE('0', 6)返回varchar(8000)，但若@val是varchar(10)，拼接后可能被隐式截断——显式转成足够长类型，如CONVERT(varchar(100), REPLICATE('0', 6)) + ISNULL(@val, '') - 如果
@val原长超 6，RIGHT(..., 6)会截掉左边，这其实是「取右 6 位」，不是「补足 6 位」，逻辑上要区分场景
跨数据库写法统一？别硬凑，优先在应用层做
想写一条 SQL 同时兼容 MySQL、PostgreSQL、SQL Server 的 LPAD？基本不可行。各库函数名、大小写、空值处理、字节/字符语义全都不一样，强行抽象只会埋下隐性 bug。
更稳妥的做法：
- 把填充逻辑提到业务代码里（Python 的
str.zfill()、Java 的String.format("%06d", n)、Go 的fmt.Sprintf("%06d", n)都按字符/数字语义工作，稳定可控 - 如果必须走 SQL（如视图、存储过程），就按目标数据库单独写，别加注释说“此处模拟 LPAD”，那只会误导后续维护者
- 特别注意日志或导出场景：用 SQL 填充后看起来对齐了，但导出到 Excel 时因字体等宽问题又错位——这时候该修显示层，不是继续调 SQL
字符集、空值、截断、大小写，四个点里漏一个，填充就失真。宁可多查一次 CHAR_LENGTH，也别赌默认行为。
