UUID主键让JOIN变慢的根本原因是其随机性导致B+树索引频繁页分裂、数据局部性差，进而降低缓存命中率、增加随机I/O；JOIN时驱动表扫描后，被驱动表回表路径分散，索引效率下降。
为什么UUID主键会让JOIN变慢——不是因为“UUID不能JOIN”
根本原因不是UUID本身，而是用uuid类型（或text/varchar）作主键时，B-tree索引节点分裂频繁、页内数据局部性差。每次INSERT都可能插入到索引任意位置，导致缓存命中率低、随机I/O高；JOIN时驱动表扫描后，被驱动表回表路径也更分散。实测v4主键写入吞吐比顺序ID低30%以上，JOIN延迟常翻倍。
优先换UUIDv7，别再用v4当主键
UUIDv7在毫秒时间戳前缀基础上拼接随机后缀，天然保持趋势递增，大幅降低B-tree页分裂概率。PostgreSQL 18已原生支持gen_random_uuid_v7()，低版本可用pg_uuidv7扩展或应用层生成。
- 建表必须用
uuid类型，不是text：避免隐式转换和索引失效 - 主键定义要显式带
CLUSTER（可选但推荐）：CLUSTER ON your_table_pkey，让物理存储尽量按主键顺序排列 - 避免在JOIN条件里对UUID字段做函数操作，例如
LOWER(id)或REPLACE(id, '-', '')——这会让索引完全失效
JOIN时确保走索引的三个硬检查点
即使主键是v7，JOIN仍可能退化为全表扫描。用EXPLAIN (ANALYZE, BUFFERS)确认以下三点：
-
type字段是否为index、index-only或bitmap index scan，而不是Seq Scan -
key是否命中你建的主键或连接字段索引（比如your_table_pkey） - 被驱动表的连接列上必须有索引——哪怕它是主键，也要确认执行计划里真用了它；如果JOIN字段是外键但没显式建索引，PostgreSQL不会自动利用主键索引加速反向查找
真正容易被忽略的是应用层传参格式不一致
前端传"99d8c87a-5730-409e-8778-5d26a969298a"，后端生成v7却用"99d8c87a5730409e87785d26a969298a"（无横线），数据库层面值就不同——JOIN结果为空或重复，比慢更致命。必须统一标准化：入库前强制小写、去横线、校验长度32、拒绝非v7格式。
