UUID用BINARY(16)替代CHAR(36)可降55%存储和30%+JOIN耗时，关键在全程二进制处理、索引对齐及格式统一，否则易致JOIN结果错误。
UUID主键做JOIN慢，根本不是“不能用”，而是默认用CHAR(36)存、用字符串比、索引页被撑爆——转成BINARY(16)能直接砍掉55%存储和30%+执行时间，但必须两端一致、索引对路、格式干净。
为什么CHAR(36)的UUID会让JOIN变卡
MySQL对CHAR(36)字段做等值比较时，是逐字节比36次，没法用CPU整数指令；更关键的是InnoDB二级索引叶子节点会完整冗余主键值——主键是36字节，每个二级索引都多存36字节，JOIN时驱动表扫描+被驱动表回表的I/O直接翻倍。实测100万行订单表，user_id从CHAR(36)换成BINARY(16)后，索引大小从42MB降到19MB，JOIN耗时从2.3秒压到0.4秒。
怎么安全地把UUID转成BINARY(16)
核心是“生成→存储→查询”全程走二进制，不经过字符串中转：
- 插入前：应用层别再用
UUID.randomUUID().toString()直插，Java用UUID.getMostSignificantBits()拼16字节数组，Python用uuid.UUID().bytes - 数据库定义：
id BINARY(16) NOT NULL PRIMARY KEY，关联字段如orders.user_uuid也必须是BINARY(16)并加索引 - MySQL 8.0+ 写法：INSERT用
UUID_TO_BIN('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11')，SELECT用BIN_TO_UUID(id)还原可读格式 - 千万别手写
UNHEX(REPLACE())——大小端处理不一致会导致JOIN结果为空或重复
JOIN还慢？先看执行计划和数据一致性
就算字段已改BINARY(16)，JOIN仍可能慢，问题常出在这两处：
-
EXPLAIN里key列没命中你建的索引，type还是ALL：说明索引没生效，检查ON子句有没有函数包裹，比如ON u.id = UNHEX(o.user_id_str)会强制全表扫描 - 应用层UUID格式不统一：有的传
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11，有的传A0EEBC999C0B4EF8BB6D6BB9BD380A11（大写无横线），UUID_TO_BIN()对二者生成的二进制值不同，JOIN结果就不可信 - 务必在入库前标准化：统一小写、带横线、校验长度、强制v7生成——这不是数据库能兜底的事
真正容易被忽略的，不是“要不要转二进制”，而是“谁在什么时候、以什么格式把UUID塞进来”。格式错一点，JOIN结果就错一片，比慢更致命。
