例如
SELECT company_ID, totalRevenue
FROM `BigQuery.BQdataset.companyperformance`
ORDER BY totalRevenue LIMIT 10
我可以看到使用和不使用LIMIT 10之间的唯一区别只是用于显示给用户的数据量不同。 在执行LIMIT之前,系统仍将首先对所有数据排序。
答案 0 :(得分:1)
以下适用于BigQuery
不一定100%在技术上都是正确的-但足够接近,因此我希望以下内容可以使您了解LIMIT N为什么在BigQuery中非常重要
假设您有1,000,000行数据和8个工作程序来处理如下查询
SELECT * FROM table_with_1000000_rows ORDER BY some_field
第1轮:要对该数据进行排序,每个工作人员将获得125,000行–因此,现在您有8个排序的集合,每组125,000行
第2轮:工作人员1将排序后的数据(125,000行)发送给工作人员2,工作3发送至工作人员4,依此类推。现在我们有4个工人,每个工人订购25万行
第三轮:重复以上逻辑,现在我们只有2个工人,每个工人生产500,000行的有序列表
第4轮:最后,只有一个工人产生最终的有序排列的1,000,000行
当然,基于行数和可用工作者的数量-轮数可以与上面的示例不同
摘要:这里的内容:
一种。我们在工作人员之间传输了大量数据–这可能是导致性能下降的一个因素
b。而且我们有机会使其中一名工作人员无法处理分配给各个工作人员的数据量。它可能早晚发生,通常会显示为“资源超出…”错误
现在,如果您将LIMIT作为查询的一部分,如下所示
SELECT * FROM table_with_1000000_rows ORDER BY some_field LIMIT 10
因此,现在–第一轮将是相同的。但是从第2轮开始-仅将前10行发送给另一位工作人员-因此,在第1轮之后的每个回合中-仅处理20行,并且仅发送前10行以进行进一步处理 希望您看到这两个过程在工作人员之间发送的数据量以及每个工作人员需要进行多少工作以对各自的数据进行排序方面有何不同
总结:
没有LIMIT 10:
•移动的初始行(第一行):1,000,000;
•已排序的初始行(第1行):1,000,000;
•移动的中间行(第2-4排):1,500,000
•整体合并的有序行(第2至4轮):1,500,000;
•最终结果:1,000,000行
限制10:
•移动的初始行(第一行):1,000,000;
•已排序的初始行(第1行):1,000,000;
•移动了中间行(第2-4排):70
•整体合并的有序行(第2至4轮):140;
•最终结果:10行
希望以上数字清楚地表明您使用LIMIT N获得的性能差异,甚至在某些情况下甚至能够成功运行查询而不会出现“资源超出...”错误
答案 1 :(得分:0)
此答案假定您要询问以下两个变体之间的区别:
PaintRenderingContext2D
在许多数据库中,如果存在涉及ORDER BY totalRevenue
ORDER BY totalRevenue LIMIT 10
的合适索引,则totalRevenue
查询可能会在找到前10条记录后停止排序。
正如您所指出的,在没有任何索引的情况下,两个版本都必须进行完整排序,因此应该执行相同的操作。
此外,如果表很大,则两者之间可能存在重大的性能差异。在LIMIT
版本中,BigQuery仅需要发送10条记录,而在非LIMIT
版本中,则可能需要发送更多的数据。
答案 2 :(得分:0)
没有性能提升。 bigQuery仍然会遍历表中的所有记录。
您可以对数据进行分区,以减少bigQuery必须读取的记录数量。这将提高性能。您可以在此处阅读更多信息: https://cloud.google.com/bigquery/docs/partitioned-tables
答案 3 :(得分:0)