UUID字段JOIN慢因VARCHAR(36)逐字符比较且主键为UUID导致二级索引膨胀；优化方案是改用BINARY(16)存储，配合UUID_TO_BIN()/BIN_TO_UUID()函数及对应索引。
MySQL 中 UUID 字段做 JOIN 条件时为什么慢
因为 UUID 默认以 VARCHAR(36) 存储，每次比较都要逐字符比对 36 字节，且无法利用 CPU 的整数比较指令；更关键的是，InnoDB 的二级索引叶子节点会完整冗余主键值——如果主键是 UUID，所有二级索引体积暴涨，JOIN 时驱动表扫描 + 被驱动表回表的 I/O 成倍增加。
把 UUID 存成 BINARY(16) 是最直接有效的优化
这步能砍掉 55% 的存储和比较开销，且无需改业务逻辑，只需在应用层做一次格式转换：
-
INSERT时：用UNHEX(REPLACE('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11', '-', ''))转为BINARY(16) -
SELECT时：用HEX(uuid_col)或CONCAT_WS('-', SUBSTR(HEX(uuid_col),1,8), ...)还原可读格式 - 建表时定义为
uuid_bin BINARY(16) NOT NULL，并加索引：INDEX idx_uuid_bin (uuid_bin) - 注意：MySQL 8.0+ 支持
UUID_TO_BIN()和BIN_TO_UUID()，比手写UNHEX/HEX更安全（自动处理大小端）
别用哈希索引替代 B+ 树索引做 JOIN
MySQL 的 HASH 索引（仅 Memory 引擎支持）不适用于 UUID JOIN 场景，原因很实在：
- 它只支持等值查询，
WHERE uuid_col = ?可以，但JOIN ON a.uuid = b.uuid在 InnoDB 下根本用不了 HASH 索引 - InnoDB 没有真正的哈希索引；所谓的 “自适应哈希索引” 是引擎内部缓存机制，不可控、不持久、不保证生效
- 即使强行换 Memory 表做 JOIN 中间结果，也会因不支持事务、不落盘、无法与 InnoDB 表直接 JOIN 而失败
JOIN 性能还卡在哪儿？得看驱动表和索引覆盖
就算 uuid 字段已转 BINARY(16)，JOIN 仍可能慢——问题常出在执行计划没走对索引：
- 检查
EXPLAIN输出中type是否为ref或更好，key是否命中你建的uuid_bin索引 - 确保被驱动表的连接字段上有索引，否则会退化为嵌套循环全表扫描（
type: ALL） - 如果只需要连接后的部分字段，把它们加进联合索引里，触发
using index（覆盖索引），避免回表 - 大表 JOIN 时，优先让小表做驱动表；可用
STRAIGHT_JOIN强制顺序，但必须确认统计信息准确，否则适得其反
真正容易被忽略的是：应用层生成 UUID 后，没做标准化就直接插入——比如有的服务传带连字符的字符串，有的传大写，有的漏了中间横线。这些会导致 BINARY(16) 值不一致，JOIN 结果为空或重复，比慢更致命。
