UUID字段JOIN必须转BINARY(16)，否则性能断崖式下跌；因VARCHAR(36)逐字符比对且二级索引冗余主键致I/O激增，改用UUID_TO_BIN()和BIN_TO_UUID()可提速近6倍并减容55%。
直接结论：UUID字段做JOIN必须转BINARY(16)，否则性能会断崖式下跌——不是慢一点，是慢几倍甚至几十倍。
为什么VARCHAR(36)的UUID会导致JOIN极慢
MySQL对VARCHAR(36)类型的UUID逐字符比对，每次JOIN都要比36字节；而BINARY(16)可直接用CPU整数指令一次比对16字节，速度差距肉眼可见。更致命的是InnoDB二级索引叶子节点会完整冗余主键值——如果主键是VARCHAR(36) UUID，所有二级索引体积暴涨，JOIN时驱动表扫描 + 被驱动表回表的I/O成倍增加。
- 常见错误现象：
EXPLAIN显示type=ALL或rows远超预期，CPU高但磁盘I/O不高（说明在内存暴力匹配） - 使用场景：事实表与维度表通过
customer_uuid关联、订单表与用户表通过user_uuidJOIN - 性能影响：未优化前JOIN耗时2.3秒，转
BINARY(16)后降到0.4秒，存储体积减少约55%
MySQL 8.0+ 正确转换方式：用UUID_TO_BIN()和BIN_TO_UUID()
别再手写UNHEX(REPLACE())和HEX()拼接逻辑——大小端处理不一致会导致JOIN结果错乱或为空。MySQL 8.0+ 提供了安全函数，自动处理字节序。
- INSERT时：
INSERT INTO users (id, name) VALUES (UUID_TO_BIN('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'), 'Alice'); - SELECT时：
SELECT BIN_TO_UUID(id) AS uuid_str, name FROM users; - 建表语句：
id BINARY(16) NOT NULL PRIMARY KEY，并确保关联字段如order.user_uuid也定义为BINARY(16)且加索引：INDEX idx_user_uuid (user_uuid)
JOIN仍慢？检查执行计划和应用层数据一致性
就算字段已转BINARY(16)，JOIN还慢，大概率是执行计划没走对索引，或者应用层传入的UUID格式不统一。
- 用
EXPLAIN确认key列是否命中你建的索引，type是否为ref或eq_ref；若仍是ALL，说明索引没生效 - 检查应用层：有的服务传
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11，有的传A0EEBC999C0B4EF8BB6D6BB9BD380A11（大写无横线），UUID_TO_BIN()对二者生成的二进制值不同，JOIN结果为空或重复 - 务必在应用层标准化：统一小写、带横线格式，再进
UUID_TO_BIN()；数据库层不做容错转换
真正容易被忽略的不是“要不要转二进制”，而是“谁在什么时候、以什么格式把UUID塞进来”——格式不一致比慢更危险，它让JOIN结果不可信。
