太多表对你有害
在数据库设计中，创建过多的表会显著影响性能和维护性。本文探讨了过度表分化（table proliferation）带来的问题，包括查询性能下降、连接操作变慢、内存管理效率降低以及开发复杂性增加。作者通过实际案例和性能基准测试，展示了表数量过多如何导致计划优化器负担加重、缓存命中率下降以及维护工作成倍增长，并提出了合理的表设计建议来避免这些陷阱。
背景速读
- PostgreSQL 是一种开源的关系型数据库，广泛应用于各类 Web 应用和企业系统中。它支持通过分区（partitioning）将一张大表拆成多个物理子表来提升管理效率。
- 该文作者 Hans-Jürgen Schönig 是 PostgreSQL 技术公司 CyberTec 的 CEO 兼资深工程师，长期从事 PostgreSQL 性能调优和培训。
- 文章的核心观点是：当数据库中表的数量过多（哪怕是分区表产生的子表）时，PostgreSQL 的查询规划器（query planner）需要为每个查询扫描所有相关表的元数据，导致规划时间显著增加，进而拖慢整体查询性能。
- 许多开发者误以为“分区越多越好”或“拆表越细越灵活”，但作者通过实际测试数据展示：当表数量达到数千甚至上万级别时，即便最终只查一个分区，规划时间的累积也会造成严重延迟。
- 这一问题的根本原因在于 PostgreSQL 的进程模型和统计信息收集机制。理解这一 trade-off 对于进行数据库 schema 设计、特别是大规模 SaaS 或时序数据场景下的表规划，具有重要的实践意义。