BigQuery 查询费用怎么控制，开发人员应该养成哪些查询习惯

BigQuery 查询费用控制与开发实践指南从扫描数据量到 Slot 容量全面降低云端分析成本

BigQuery 的优势在于能够直接面对海量数据进行分析，而不需要开发人员自己维护传统数据仓库中的大量计算和存储基础设施。但云数据仓库有一个很现实的问题：SQL 写得出来，并不意味着这条 SQL 的运行成本合理。

一条看起来只有几十行的查询，如果每次都扫描数 TB 数据，再通过复杂 JOIN、聚合和排序完成计算，长期运行下来可能产生非常可观的计算成本。因此，BigQuery 的成本控制不能只放在财务部门，而应该成为数据工程师、分析师和应用开发人员日常写 SQL 时的一部分。

BigQuery 当前的查询计算主要存在两种计费模式。按需计算模式主要按照查询处理的数据量计费；容量计算模式则通过 BigQuery Editions、Reservation 和 Slot 容量管理计算资源。所有查询都会使用 Slot，但这并不意味着默认情况下每条查询都是按照“用了多少 Slot”直接收费。

BigQuery 查询为什么会产生费用

对于采用按需计算的项目，最重要的成本指标不是 SQL 有多少行，而是查询实际需要处理多少数据。

例如一张 20 TB 的表，如果查询条件能够有效利用分区，只读取其中几十 GB，那么成本和直接扫描整张 20 TB 表完全不同。

这也是 BigQuery 成本优化最核心的原则：减少不必要的数据读取。

查询验证器和 dry run 可以在真正执行查询之前估算需要处理的数据量。开发人员在编写复杂 SQL 时，尤其应该养成先检查处理数据量的习惯，而不是写完以后直接运行。Google 官方也建议使用查询验证器或者 dry run 进行执行前估算。

需要注意，dry run 给出的处理量属于估算信息，并不应该简单理解成最终账单金额。实际费用还会受到计费模式、免费额度、折扣等因素影响。

Slot 很重要，但不能把 Slot 和查询费用混为一谈

BigQuery Slot 是执行查询所使用的虚拟计算资源。查询运行过程中，BigQuery 会根据数据量、查询复杂度以及可用计算容量动态使用 Slot。

在按需模式下，用户主要按照查询处理的数据量付费，而不是根据某条 SQL 在某一秒钟用了多少 Slot 来直接计费。

如果企业采用 BigQuery Editions 和容量型计算，则情况不同。企业可以通过 Reservation 管理计算容量，Slot 成为容量规划和并发控制的重要指标。

因此，开发人员看到一条 SQL 使用了大量 Slot，并不能直接得出“这条 SQL 一定按照 Slot 数量收费”的结论。成本分析必须先确认项目采用的是哪一种计算计费模式。

分区是控制扫描成本的第一工具之一

如果一张表主要按照日期进行查询，例如订单、日志、访问记录和交易数据，那么非常适合考虑时间分区。

例如一个包含多年业务数据的订单表，大部分查询实际上只关心最近 7 天或者最近一个月。如果表已经按照日期分区，并且查询条件能够有效过滤分区，BigQuery 就不需要读取所有历史数据。

因此，类似下面这种条件通常比完全不限制时间范围更加合理：

WHERE order_date >= '2026-08-01'

具体应该选择哪一个分区字段，则要根据真实查询模式决定，而不是为了“分区”而分区。

分区字段选错同样可能没有多少收益。如果绝大多数查询按照客户 ID 查询，却选择一个完全不相关的字段作为主要优化方向，最终效果可能并不理想。

BigQuery 官方也明确建议针对典型查询模式合理使用分区和聚类，以减少读取的数据量。

聚类不是传统数据库里的索引

原稿中的“对高基数列进行索引优化”容易让传统 MySQL 或 SQL Server 开发人员产生误解。

BigQuery 并不是通过传统 B-tree 索引来解决所有查询性能问题。BigQuery 的聚类机制会根据指定列组织数据，使查询在适当条件下能够进行数据块剪枝。

例如一张已经按照日期分区的订单表，还可以根据客户 ID、产品 ID 等典型过滤字段进行聚类。

但聚类字段的选择不能靠“基数越高越好”这一条规则决定。应该观察真实查询中的过滤、排序和 JOIN 模式，并根据实际工作负载选择聚类字段以及字段顺序。

聚类列的顺序也有意义。对于多个聚类字段，查询如果能够从前面的聚类字段开始进行有效过滤，通常更容易获得数据块剪枝收益。

不要迷信 SELECT * 加 LIMIT

这是很多开发环境里最常见的 BigQuery 成本误区之一。

开发人员经常写：

SELECT * FROM large_table LIMIT 100

然后认为自己只取 100 行，所以不会产生多少扫描成本。

对于普通非聚类表，这种理解是错误的。LIMIT 限制的是最终返回的行数，并不会自动让 BigQuery 少读取整张表的数据。Google 官方明确提醒，对于非聚类表，LIMIT 本身不能作为降低扫描成本的方法。

开发阶段如果只是想查看数据样本，可以使用 BigQuery 的 Preview 功能，而不是反复执行大型 SELECT * 查询。

正式 SQL 也应该尽量只选择需要的字段，而不是长期使用 SELECT *。读取不需要的大型 STRING、JSON 或其他宽字段，不仅增加 I/O，也可能增加后续计算和结果物化成本。

JOIN 和聚合才是复杂查询的另一个成本中心

减少扫描量只是第一步。

如果两个大型数据集进行 JOIN，数据移动、排序、聚合和数据倾斜都可能成为性能瓶颈。

因此不能只看 SQL 的 FROM 和 WHERE，还需要观察查询计划中的各个 Stage。

如果某个阶段读取的数据量巨大，同时又产生大量计算或者数据 Shuffle，就应该进一步检查 JOIN 条件、聚合逻辑、数据分布和是否存在重复扫描。

对于经常重复执行的大型分析，可以考虑提前物化中间结果或者建立汇总表。BigQuery 官方也建议，对于复杂、多阶段的查询，在适合的情况下将结果分阶段物化到目标表，以避免每次重新从大型基础表读取大量数据。

查询缓存可以降低重复查询成本，但不能当成万能缓存

BigQuery 对符合条件的重复查询可以使用缓存结果。

如果完全相同的查询能够命中缓存，系统可以直接返回已经生成的结果，而不需要重新执行完整查询。缓存结果通常存放在临时表中，命中缓存的查询不会产生查询费用。

但应用架构不能建立在“这条 SQL 永远会命中缓存”的假设上。

查询文本、数据变化以及其他缓存条件都可能影响缓存是否能够复用。因此，对于稳定、高频、业务关键的聚合结果，更应该考虑物化视图、汇总表或者其他明确的数据建模方案。

物化视图适合一些能够重复计算的聚合型查询，它可以提前保存计算结果，让后续查询减少对底层大表的读取。

Maximum bytes billed 是非常实用的保险丝

对于开发环境尤其重要的一项功能，是为查询设置 maximum bytes billed。

它的作用很直接：如果 BigQuery 在执行前估算这条查询需要处理的数据量超过设定上限，可以直接拒绝执行，从而避免开发人员因为一个错误 SQL 意外扫描数 TB 数据。

例如开发人员正在修改一个生产环境分析查询，原本只应该读取当天分区，却因为 WHERE 条件写错导致查询可能扫描整个历史表。设置合理的 maximum bytes billed 后，这类查询可以在真正产生大额计算费用之前被拦截。

对于开发项目、测试项目以及分析师环境，这类限制尤其值得建立为默认规则。

不要把 Cloud Storage 当成 BigQuery 历史表的自动冷存储

原稿把 BigQuery 存储优化和 Cloud Storage 生命周期策略直接连在一起，这需要修正。

BigQuery 原生表有自己的存储计费机制和数据生命周期能力。对于长期不修改的数据，BigQuery 本身存在长期存储价格机制；如果表或者分区连续 90 天没有修改，在符合条件的情况下可以进入长期存储价格。

如果业务确实需要把历史数据归档到 Cloud Storage，那属于数据架构层面的冷热分层，而不是简单设置一个 Cloud Storage 生命周期规则就等于优化 BigQuery 存储。

因此应该先判断数据是否仍然需要作为 BigQuery 原生表直接分析，再决定是否归档到 Cloud Storage。

数据存储优化也应该看实际访问模式

BigQuery 当前还支持不同的存储计费模型，包括逻辑存储和物理存储等选项。具体哪一种更合适，需要结合数据修改频率和实际存储模式评估。

尤其需要注意频繁覆盖大表的问题。

如果工作负载不断使用 CREATE OR REPLACE、TRUNCATE 或其他方式重复重写大型表，那么在特定存储计费模式下，Time Travel 和 Fail-safe 等机制也可能影响实际存储成本。

因此成本分析不能只看“表现在有多少 TB”，还应该观察表的修改频率、分区变化、历史版本以及实际生命周期。

跨区域数据传输不要简单等同于 BigQuery 查询费

BigQuery 的计算费用、存储费用和网络传输费用属于不同问题。

如果数据分布在不同区域，跨区域读取、复制、导出或者与其他 Google Cloud 服务交互时，可能产生额外的数据传输成本。

因此数据平台设计阶段应该尽量让高频协作的数据处理靠近主要计算位置。

但也不能简单地说“使用 VPC Peering 就可以降低 BigQuery 查询的跨区域成本”。VPC Peering 主要解决 VPC 网络之间的连接问题，并不是 BigQuery 查询成本优化工具。

同样，Dataflow 也不是专门用来“把 BigQuery 数据本地化以降低网络费”的万能方案。Dataflow 是否合适，应该根据数据流处理、转换、实时处理和管道架构决定。

用查询计划找到真正的瓶颈

BigQuery 的 Query Plan 和 Timeline 是开发人员分析复杂 SQL 非常重要的工具。

查询执行计划能够显示不同 Stage 的读取、计算、Shuffle 和输出情况。

如果某个 Stage 处理了异常庞大的数据量，或者出现明显的数据倾斜，就应该进一步分析 JOIN、GROUP BY、聚合以及过滤条件。

例如某个 Stage 的最大计算时间明显高于平均水平，可能说明数据分布不均匀，一部分计算节点承担了远高于其他节点的工作量。

因此，优化 SQL 不能只看“执行了多少秒”，还应该观察数据读取量、各 Stage 的处理量、Shuffle、计算时间以及 Slot 使用情况。

INFORMATION_SCHEMA 是成本治理的重要数据源

当 BigQuery 进入生产环境以后，不能依靠开发人员偶尔打开控制台检查费用。

可以利用 BigQuery 的 INFORMATION_SCHEMA 视图分析历史查询，例如查询执行时间、处理数据量、用户、项目以及作业类型等信息。

通过这些数据可以建立团队自己的查询成本画像。

例如可以找出最近一个月处理数据量最大的 SQL，找出最频繁执行的查询，找出某个团队突然增加的扫描量，也可以进一步建立项目、用户和工作负载维度的成本归因。

对于大型数据平台，这比简单查看月底 Cloud Billing 账单更有价值，因为账单告诉你“花了多少钱”，而查询历史更容易帮助你找到“为什么花这么多钱”。

成本控制应该放在开发流程里

一个成熟的数据团队不应该等到月底账单暴涨以后才开始优化。

开发阶段可以要求大型查询先进行 dry run；生产项目可以设置 maximum bytes billed 或项目级成本控制；团队可以使用 Cloud Billing Budgets 和告警监控整体支出；生产环境再结合 INFORMATION_SCHEMA、Query History 和查询执行计划持续分析。

对于经常运行的 SQL，则应该建立基线。

例如某个报表过去每天处理 200 GB，突然变成每天 8 TB，这种变化就应该进入异常检测范围。

成本异常往往不是 BigQuery 自己“突然变贵”，而是数据量增加、分区失效、SQL 改动、JOIN 扩大、重复查询或者业务流量变化造成的。

BigQuery 本身也提供项目和用户级的成本控制能力，以及 maximum bytes billed 等限制机制，可以把这种风险从人工检查变成系统控制。

BigQuery 架构不应该简单堆工具

一个合理的数据平台可以让 Dataflow、BigQuery、Cloud Storage 和 BI 工具分别承担适合自己的工作，但没有必要为了“云原生架构”把所有产品都加入进去。

Dataflow 更适合承担数据处理和数据管道任务；BigQuery 负责分析型数据仓库和 SQL 分析；Cloud Storage 适合对象数据、数据湖、归档和大规模文件存储；Looker 等 BI 工具负责面向业务用户的数据分析和可视化。

关键不是组件越多越先进，而是数据在哪里存、谁负责处理、多久访问一次、查询模式是什么，以及每个阶段的成本是否合理。

BigQuery 成本优化最后还是要回到一个非常朴素的工程原则：不要让计算系统读取那些根本不需要读取的数据。分区负责缩小数据范围，聚类帮助进行数据块剪枝，合理的列投影减少读取和物化，正确的 JOIN 和聚合减少计算与 Shuffle，缓存和物化结果避免重复工作，maximum bytes billed 防止错误查询造成失控成本，而查询计划、Query History 和 INFORMATION_SCHEMA 则帮助工程师找到真正的成本来源。

当这些措施进入开发规范以后，BigQuery 的成本控制就不再是月底看账单时的一次性补救，而会变成数据工程生命周期中的正常组成部分。对于小规模项目，这可能只是避免一次误操作；对于每天处理 TB、PB 级数据的生产数据平台，它则可能决定整个分析系统的长期运营成本。