将数据库数据拆分为多个表而不是将所有内容存储在 PostgreSQL 的一个表中是否是个好主意？

【问题标题】：Will it be a good idea to split database data into multiple tables instead of storing everything in one table for PostgreSQL?将数据库数据拆分为多个表而不是将所有内容存储在 PostgreSQL 的一个表中是否是个好主意？
【发布时间】：2020-12-01 06:54:05
【问题描述】：

我有一个用例，每个数据行都应该按时间访问，并且某些键和键的数量可能在 1000 到 10000 之间变化。我有两个选择：将所有内容存储在一个表中并按键和时间戳索引或存储每个键的数据都在一个单独的表中，所以我最终会得到数千个表。从存储和访问速度的角度来看，最好的方法是什么？没有必要在键之间加入，也许很少。我打算使用 PostgreSQL。

【问题讨论】：

这称为partitioning - 但从存储的角度来看，它不会改变任何东西，只会对非常狭窄的用例进行性能改进。您希望该表有多少行？
@a_horse_with_no_name，非常感谢。最多 1TB 的行。

标签： database postgresql

【解决方案1】：

正如评论中提到的，这将是自旋分区，因此您可以考虑声明性列表分区。由于10000个分区已经很多了，你可以将几个key组合成一个分区。

这样做的主要优点是：

很容易删除单个分区中的所有数据（DROP TABLE）
如果桌子真的很大，autovacuum 会少很多痛苦

但是，您不应该期望典型的查询会变得更快。如果

它们在WHERE 条件中具有分区键，并且需要顺序扫描（索引扫描的速度几乎与表大小无关，但也许更好的数据局部性会给您带来一点好处）
他们沿着分区边界计算聚合或连接

如果由于分区可以省略索引或索引列，这也是一个小收获。

无论如何，如果您希望至少有数亿行，我只会考虑分区。

【讨论】：

谢谢，是的，我正在考虑数亿行甚至更多。