问当我们使用限制时，有什么性能效益吗？

EN

以下适用于BigQuery

不一定100%的技术正确，但足够接近，所以我希望下面能给你一个为什么限制N是非常重要的考虑在BigQuery

假设您有1,000,000行数据和8个处理查询的工作人员，如下所示

SELECT * FROM table_with_1000000_rows ORDER BY some_field

第1轮:要对此数据进行排序，每个工作人员将得到125,000行-因此，现在您有8组排序集，每组为125,000行。

第2轮: Worker #1将其排序的数据(125,000行)发送给工作人员#2，#3发送到#4，依此类推。现在我们有4名工人，每个产品都有250,000行。

第3轮:上面的逻辑重复了，现在我们只有两个工人，每个人都有500,000行的有序列表。

第4轮:最后，只有一个工作人员生成1,000,000行的最终排序集

当然，根据行数和可用工作人员数，轮数可能与上述示例中的不同。

摘要:我们这里有：

我们有相当多的数据在工人之间传输--这可能是性能下降的一个相当大的因素。

我们有机会让其中一名工人无法处理分配给相应工人的大量数据。这种情况可能发生得早或晚，通常表现为“资源超过…”错误类型

所以，如果您有限制作为查询的一部分，如下所示

SELECT * FROM table_with_1000000_rows ORDER BY some_field LIMIT 10 

所以，现在-第一轮将是一样的。但是从第2轮开始，只有前10行将被发送给另一位工人，因此在第一轮之后的每一轮中，只有20行将被处理，只有前10行将被发送到进一步处理，希望您看到这两个进程在工人之间发送的数据的数量以及每个工人需要应用多少工作来对各自的数据进行排序时有多么不同。

概括地说：

无限制10：

初始行移动(第1轮)：1 000 000行；

最初排序行(第1轮)：1 000 000行；

中间行移动(第2-4轮)：1 500 000行

合并后的总体有序行(第2-4轮)：1,500,000；

最终结果:1 000 000行

限制为10：

初始行移动(第1轮)：1 000 000行；

最初排序行(第1轮)：1 000 000行；

中间行移动(第2-4轮)：70行

总体合并有序行(第2-4轮)：140行；

最终结果: 10行

以上数字清楚地显示了使用极限N所获得的性能差异，在某些情况下甚至可以在没有“资源超过.”的情况下成功地运行查询。错误

这个答案假设您询问的是以下两个变体之间的区别：

ORDER BY totalRevenue
ORDER BY totalRevenue LIMIT 10

在许多数据库中，如果存在涉及totalRevenue的适当索引，则LIMIT查询可以在找到前10条记录后停止排序。

在没有任何索引的情况下，正如您所指出的，这两个版本都必须执行完整的排序，因此应该执行相同的排序。

此外，如果表很大，两者之间可能存在很大的性能差异。在LIMIT版本中，BigQuery只需要跨10个记录发送，而在非LIMIT版本中，可能需要发送更多的数据。

没有性能上的提升。bigQuery仍在检查表上的所有记录。

您可以对数据进行分区，以减少bigQuery必须读取的记录数量。这将提高业绩。您可以在这里阅读更多信息：https://cloud.google.com/bigquery/docs/partitioned-tables