微小的 Postgres 元数据表如何拖慢你最大的查询
这篇文章揭示了 Postgres 中那些看似微不足道的系统元数据表（如 pg_class、pg_attribute 等）如何成为大型查询的性能瓶颈。虽然这些表通常很小，但高频的锁竞争和低效的统计信息收集机制，会在高并发场景下严重拖慢大查询的执行速度。文章还提供了优化建议，包括调整统计信息收集参数、使用分区表以及合理配置 autovacuum 等策略。
背景速读
PostgreSQL 是一个开源关系型数据库，广泛用于各类核心业务系统。它的查询计划器（query planner）负责决定如何最高效地执行 SQL 语句，而这个决策严重依赖元数据统计信息（如表行数、列值分布等），这些信息存储在系统表（如 pg_class、pg_statistic）中。
- 问题核心：PostgreSQL 的元数据表非常小（几十到几百 KB），但高并发下所有查询都要读取它们来生成执行计划。当这些“小表”被频繁争用，就变成了全局瓶颈——查询还没开始跑数据，就已经在等待元数据锁或 CPU 时间。
- 本文揭露了一个反直觉现象：不是大表扫描拖慢系统，而是这些“微小但繁忙”的系统表在高负载下限制了整体吞吐量。类似原理也见于其他数据库（如 MySQL 的 data dictionary 争用）。
- 作者来自 TigerData，一家专注于 PostgreSQL 性能优化和数据库内核修改的公司。文章面向的是对数据库有一定了解但可能没深究过元数据层争用的工程师。
- 关键参数：autovacuum 和统计信息更新频率控制着元数据表被重写的节奏；不合理的配置会加剧锁竞争。读者可借此理解为何有时加索引或调 SQL 无法缓解的“神秘慢查询”，根因可能在上层元数据层。