join字段类型或长度不一致本身不直接导致索引失效，而是触发隐式转换使被驱动表索引完全失效，explain显示type=all、key=null；须用show full columns和hex()确认真实差异，再统一type/collation或建计算列索引。
JOIN 字段类型或长度不一致本身不直接“导致”索引失效，而是触发 MySQL 的隐式转换——它会把整列（比如 b.bid）逐行转成另一类型/长度再比对，结果就是被驱动表的索引完全失效，EXPLAIN 里 type=ALL、key=NULL。
真正要治的不是“长度”，是「比较是否发生在同一语义层」。下面分三块说清楚怎么做、为什么、容易踩什么坑。
先用 SHOW FULL COLUMNS 确认是不是真有差异
别凭 DESCRIBE table_a 或建表语句猜。字段看着都是 VARCHAR(6)，但可能一边是 CHAR(6)（自动右补空格），一边是 VARCHAR(4)（不补），JOIN 时 '123 ' ≠ '123'。
- 运行
SHOW FULL COLUMNS FROM table_a LIKE 'aid'和SHOW FULL COLUMNS FROM table_b LIKE 'bid'，重点看Type、Collation、Extra - 用
HEX(a.aid)和HEX(b.bid)查二进制内容——空格、不可见字符、编码错位全暴露 - 检查
@@collation_connection：即使字段定义一致，连接层 collation 不同，字面量字符串也会被转错
ALTER TABLE MODIFY 必须同时指定 CHARACTER SET 和 COLLATE
只改 CHARACTER SET 不改 COLLATE，等于白干。MySQL 比较依赖的是排序规则，不是字符集名字本身。
- 错误写法：
ALTER TABLE b MODIFY bid VARCHAR(6) CHARACTER SET utf8mb4——Collation还是旧的 - 正确写法：
ALTER TABLE b MODIFY bid VARCHAR(6) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs—— 必须和a.aid的Collation完全一致 - 大表操作锁表严重，MySQL 8.0+ 可加
ALGORITHM=INPLACE减少影响，但需确认无全文索引 - 改完立刻跑
SHOW CREATE TABLE b验证，再EXPLAIN看key是否出现索引名
LPAD / RPAD 补长度前必须处理 NULL 和截断
很多人写 LPAD(b.bid, 6, '0') 就上线，结果发现关联不上——因为 b.bid 是 NULL，结果整个表达式为 NULL，JOIN 条件永远不成立；或者 b.bid = '1234567' 被硬截成 '123456'，本该匹配的记录错失。
-
LPAD(COALESCE(b.bid, ''), 6, '0')是底线，但更稳妥的是先过滤：WHERE CHAR_LENGTH(COALESCE(b.bid, '')) - PostgreSQL 注意：
lpad('', 6, '')会报ERROR: zero-length padding string，填充符不能为空字符串 - 长期推荐方案：建计算列索引，例如
ALTER TABLE b ADD COLUMN bid_padded VARCHAR(6) AS (LPAD(TRIM(COALESCE(bid, '')), 6, '0')) STORED，再在bid_padded上建索引
LPAD 或 CONVERT 很难兜住所有边界。真正稳的做法，是应用层读出数据后统一标准化（去空格、转大小写、补零），SQL 只做干净的等值匹配。字段对齐不是拼长度，是确保每一次比较都落在同一语义平面上。
