两条腿不一样长的治疗需先明确病因，再选择鞋垫调整、康复训练、肢体延长术或截骨矫形术等针对性方法。
直接补长度不是万能解法，关键得先确认是不是真该补——很多“长度不一致”其实是类型或编码没对齐导致的假象。
先查清字段实际长度和字符集
很多人一看到 b.bid 是 VARCHAR(4)，a.aid 是 VARCHAR(6)，就急着 LPAD(b.bid, 6, '0')，结果发现关联不上。问题往往不在长度，而在：
-
b.bid存的是'123'，但字符集是latin1，而a.aid是utf8mb4，隐式转换时字节错位 -
b.bid实际含前导空格或不可见字符（比如CHAR(13)），LENGTH()看是 4，TRIM()后只剩 3 -
a.aid定义为CHAR(6)（固定长度），会自动右补空格；b.bid是VARCHAR(4)，不补——JOIN 时'123'≠'123 '
实操建议：
运行 SELECT COL_LENGTH('a', 'aid'), COL_LENGTH('b', 'bid')（SQL Server）或 SHOW FULL COLUMNS FROM a LIKE 'aid'（MySQL）看真实定义；
用 HEX(b.bid) 和 HEX(a.aid) 对比二进制内容，比肉眼看更准。
LPAD/RPAD 补全前必须处理 NULL 和截断风险
LPAD(b.bid, 6, '0') 在 b.bid 为 NULL 时直接返回 NULL，JOIN 条件失效；若 b.bid 原长已超 6，还会被硬截成 6 位，导致本该匹配的 '1234567' 变成 '123456' 错配。
- 务必套一层
COALESCE(b.bid, '')或ISNULL(b.bid, '')（SQL Server） - 加长度判断：MySQL 中可写
LPAD(COALESCE(b.bid, ''), GREATEST(6, CHAR_LENGTH(COALESCE(b.bid, ''))), '0')，但更推荐先WHERE CHAR_LENGTH(COALESCE(b.bid, '')) 过滤异常值 - PostgreSQL 注意：
lpad()不接受空字符串作填充符，lpad('', 6, '')会报ERROR: zero-length padding string
比 LPAD/RPAD 更稳的替代方案
补零只是表象，本质是要让两个字段在比较时语义一致。以下方式容错更强：
- 统一转数字再比：
CAST(COALESCE(b.bid, '0') AS SIGNED) = CAST(COALESCE(a.aid, '0') AS SIGNED)（适用于纯数字 ID） - 用
TRIM()+RTRIM()清理空格后再补：LPAD(TRIM(b.bid), 6, '0')，避免空格干扰 - 建计算列索引（长期方案）：
ALTER TABLE b ADD COLUMN bid_padded AS (LPAD(TRIM(COALESCE(bid, '')), 6, '0')) STORED，然后在该列上建索引 - 跨库或异构系统联查时，优先在应用层做标准化，SQL 层只负责等值匹配
最容易被忽略的排序规则（collation）冲突
即使长度、类型、字符集全一致，a.aid 的 collation 是 utf8mb4_0900_as_cs（区分大小写+重音），而 b.bid 是 utf8mb4_unicode_ci（不区分大小写），JOIN 仍可能漏匹配——因为比较逻辑本身就不一样。
验证命令：SHOW FULL COLUMNS FROM a LIKE 'aid'; 和 SHOW FULL COLUMNS FROM b LIKE 'bid'; 对比 Collation 列；
临时修复：在 JOIN 条件中显式指定 ON b.bid COLLATE utf8mb4_unicode_ci = a.aid COLLATE utf8mb4_unicode_ci；
但注意，加 COLLATE 会让索引失效，除非你提前建了对应 collation 的函数索引。
