从logs.nobids_05中选择DATE（request_time）限制1给了我“3.48 GB处理”，考虑到request_time是每行中出现的字段，这有点多了。
在许多其他情况下，只需触摸列自动将其总大小添加到成本中。例如，
select * from logs.nobids_05 limit 1
给我“这个查询将在运行时处理274 GB”。我确定bigquery不需要读取274GB来输出1行数据。
2019更新：如果您对表格进行聚类，那么SELECT * LIMIT 1的成本将会降至最低。
使用BigQuery运行“SELECT * FROM big_table LIMIT 1”将相当于这样做：https://www.youtube.com/watch?v=KZ-slvv_ZT4。
BigQuery是一个分析数据库。它的架构和定价针对大规模分析进行了优化，而不是单行处理。
BigQuery中的每个操作都涉及全表扫描，但只涉及查询中提到的列。目标是获得可预测的成本：在运行查询之前，您可以知道将涉及多少数据，因此需要花费其成本。查询一行似乎是一个很大的代价，但好消息是成本保持不变，即使查询变得更加复杂和CPU密集。
偶尔你可能需要运行单行查询，而且成本似乎过高，但这里的假设是你使用这个工具来大规模地分析数据，并且存储数据的总体成本应该是比其他可用的工具更具竞争力。由于您一直在使用其他工具，我很乐意在实际案例场景中看到分析会话的总成本比较。
顺便说一句，BigQuery有一个更好的方法来做相当于“SELECT * LIMIT x”。它是免费的，它依赖于REST API而不是查询：
https://developers.google.com/bigquery/docs/reference/v2/tabledata/list
这就是说，感谢您的反馈，因为在使定价更复杂和更适合其他工作的工具之间存在平衡工作 - 这种平衡建立在我们得到的反馈之上。
我不认为这是一个错误。 “当您运行查询时，即使您对结果设置了明确的LIMIT，也会根据您选择的列中处理的总数据向您收取费用。” （https://developers.google.com/bigquery/pricing#samplecosts）