Andrew Atkinson：PostgreSQL 18 使用 UUID V7 实现 23 倍插入加速
内容提要
PostgreSQL 18 采用 UUID v7 主键后，插入性能显著提升，最高达 23 倍。相比 v4 的随机性，v7 的时间顺序性减少了索引页分裂和磁盘读取。切换需执行 ALTER TABLE，但会锁表，通过设置短锁超时和重试机制解决。尽管 v7 会暴露创建时间，但整体收益高，已成为新默认选择。
延伸解读
性能提升的适用场景
文章指出，并非所有表在切换到 UUID v7 后都有明显性能提升，只有部分高频插入的表（如每分钟 12000 次的批量插入）获得了显著加速，最高达 23 倍。对于低频操作的表，变化可能不明显。因此，在考虑迁移时，应优先评估高并发插入场景，避免对所有表一刀切。
锁表问题的实用解法
修改列默认值需要 ACCESS EXCLUSIVE 锁，会阻塞所有读写操作。作者通过设置 lock_timeout 为 50ms、statement_timeout 为 100ms，并配合重试机制（最多 50 次，带随机退避）成功在不停机的情况下完成迁移。对于极高负载的表，还准备了主动取消阻塞查询的方案，但最终未使用。这为类似场景提供了可操作的参考。
UUID v7 的隐私权衡
UUID v7 的前几位包含时间戳，因此会暴露记录的创建时间，这可能成为隐私或安全方面的顾虑。相比之下，UUID v4 不包含时间信息。文章提醒读者需要根据业务需求权衡性能提升与信息泄露的风险，并非所有场景都适合使用 v7。
Q&A
PostgreSQL 18 中 UUID v7 相比 v4 在插入性能上有多大提升？
根据文章，切换到 UUID v7 后，某些表的插入性能提升显著，最高可达 23 倍。例如，一个每秒执行 12000 次的插入查询，平均执行时间从 0.7ms 降至 0.03ms。
为什么 UUID v4 会导致插入性能差？
UUID v4 是随机生成的，缺乏单调性，导致新插入的索引条目可能落在不同的索引页上，无法利用最近访问的“热”页，增加了磁盘读取和页分裂，从而降低了插入性能。
如何将 PostgreSQL 中的 UUID 主键默认值从 v4 改为 v7？
可以使用 ALTER TABLE 语句修改列默认值，例如：ALTER TABLE my_table ALTER COLUMN id SET DEFAULT uuidv7(); 但该操作需要 ACCESS EXCLUSIVE 锁，会阻塞所有读写操作。
在修改表默认值时，如何处理锁表问题？
通过设置短锁超时（如 lock_timeout = '50ms'）和重试机制来解决。对于高负载表，可以使用 PL/pgSQL 循环重试函数，尝试最多 50 次，并在重试之间加入 50-250ms 的随机退避。
UUID v7 有什么缺点？
UUID v7 的前几位包含时间戳，因此会暴露记录的创建时间，这可能被视为隐私泄露。而 UUID v4 不会暴露创建时间。
在哪些情况下，即使重试也无法获得锁？如何应对？
对于持续高负载的表，即使多次重试也可能无法获得锁。此时可以主动监控并取消持有锁的查询，使用 pg_cancel_backend(blocking_pid) 来终止阻塞进程，从而为 ALTER TABLE 创造窗口。
文章中提到哪些表获得了显著的性能提升？
文章列出了 5 个表，分别获得了 6x、8x、9x、20x 和 23x 的加速。其中 Table A 获得了 23x 加速，Table B 9x，Table C 6x。
