如果我有一个遍历每一行的查询，那么用 10,000,000 行对我的数据库表进行分区是否有意义？答案

【问题标题】：Does it make sense to partition my database table with 10,000,000 rows if I have a query that goes through every row?如果我有一个遍历每一行的查询，那么用 10,000,000 行对我的数据库表进行分区是否有意义？
【发布时间】：2021-02-06 03:51:02
【问题描述】：

我有一个包含 15 列和 10,000,000 行数据的评论表的 postgres 数据库。

**Columns**
id
product_id
_description
stars
comfort_level
fit
quality
recommend
created_at
email
_yes
_no
report

我想获得每条评论并将其放到我的前端，但由于这有点不切实际，我决定使用以下查询仅获得 4,000 条评论：SELECT * FROM reviews ORDER BY created_at LIMIT 4000;。使用索引，这非常快（6.819ms）。我认为这可能会更快，那么在这种情况下分区会有所帮助吗？或者甚至在检索所有 10,000,000 条评论的情况下？还是拆分表并在查询中使用 JOIN 子句更有意义？

【问题讨论】：

试图加快对 10,000,000 行表的查询需要 0.006819 秒，这似乎是一件愚蠢的事情。该索引似乎正在解决您的问题。

标签： sql database postgresql indexing partitioning

【解决方案1】：

这个查询肯定会因为分区而变慢：

充其量，您将表按created_at 分区，这样只会扫描一个分区。但是必须排除其他分区，这在查询计划或执行期间需要额外的时间。最坏的情况是，表没有被created_at分区，你必须扫描所有的分区。

请注意，索引扫描的速度不取决于表的大小。

我不知道你的问题是什么。 4000 行 7 毫秒对我来说听起来还不错。

【讨论】：

好的，我明白了。虽然索引使查询所有 10,000,000 行的速度变慢，但这是否很奇怪？没有索引，大约需要 46 秒，但使用它，需要 10 分钟。有没有其他方法可以加快对所有 10,000,000 的查询？
很难说没有看到EXPLAIN (ANALYZE, BUFFERS) 输出。

【解决方案2】：

10M 行位于分类为“小”的表范围的顶端。在您达到至少 50M 行之前，我不会担心任何花哨的事情。

【讨论】：