我有不同版本的Bigquery标准脚本，即我遵循标准API here。我试图找出Matlab风格的timeit或热身时间测量来测试不同的脚本：
版本A：具有模块化代码的非常易读的代码
WITH a AS
(
SELECT * FROM SOURCE
),
a_ AS
(
SELECT ... FROM a
)
SELECT * FROM a_
版本B：带有子查询的非常难以理解的代码，但声称效率很高
SELECT * FROM (SELECT * FROM (SELECT * FROM SOURCE))
如何在Google Bigquery中对不同的标准SQL查询进行时间和基准测试？
要解决的可能观点
我是否需要像Matlab一样预热BQ标准SQL查询？
版本A和B之间的常见性能差异是什么？任何优点和缺点？你怎么能在Bigquery中证明这一点？
可用于两种不同方法的任何文档或建议（过度使用子查询与模块化编码）？
答案 0 :(得分：0)
我总结了这些评论，并从成本的角度背诵了加速机会。
A演示了CTE（公用表格表达式），而B演示了像子集一样的子查询。用户Used_By_Already已经评论说差异在性能上无关紧要，因此不会传达加速机会。
“不。这与我试图传达的内容相反。您可以使用几乎任何子查询并使其成为cte，反之亦然，在您的问题中采用ctes类型并使其成为子查询。净效应最有可能为零或无法衡量。“
重要的是预先过滤，更多here由Mikhail Berlyant在评论中转发。因此，您可以通过尽早预先过滤数据来提高查询效率。
作为旁注，更多的早期过滤和因此更少的计算可能不会影响充电，更多here，因为充电是基于输入数据，而不是基于计算量。因此，对于加速机会的查询优化在Bigquery中就货币成本而言毫无意义，即使您可以节省一些时间。