当数据查询从“分析师每天提交几十条 SQL”变成“AI Agent 每分钟生成数千条查询”时，传统的性能优化流程会迅速失效。执行计划分析、统计信息维护、查询提示和容量预估都需要人工介入，而 Agent 生成的 SQL 数量、参数组合和并发度已经超出人工逐条调优的范围。
BigQuery 给出的方向不是增加更多调优旋钮，而是让查询处理器自己学习历史执行结果、选择物理执行路径，并将性能提升直接转化为更低的 slot 消耗。根据其 2025 年基准结果，这些改进带来了最高 35% 的查询性能提升，以及最多 40% 的查询处理成本下降。具体收益仍取决于查询形态、数据分布和计算模型，不能把峰值数字直接当作所有工作负载的预算依据。
从静态优化器走向闭环学习
传统查询优化器主要依赖表统计信息、元数据和基数估算。对于多表连接、快速变化的数据，以及分布严重倾斜的字段，这些估算很容易偏离实际运行情况。
BigQuery 的历史优化机制 History-Based Optimizations，简称 HBO，在这些静态信息之外记录过去查询的运行时统计。当相同或相似的查询再次出现时，系统可以复用已被证明有效的优化策略，并避开曾经造成回退的选择。
这个机制的关键不只是“记住更快的计划”，而是形成一个带保护措施的闭环：
- 只在系统对收益有较高置信度时应用历史优化。
- 应用后继续测量真实执行结果，而不是假设优化一定有效。
- 如果收益不明显、性能回退或执行失败，立即撤销对应策略。
- 对参数敏感型查询识别数据倾斜，避免只更换一个
WHERE条件就触发严重回退。
因此，仪表盘、ELT 流水线和 Agent 应用不需要改写 SQL、调整 Schema 或增加查询提示，就可能从历史执行经验中获益。摘要中的企业案例显示，P90 执行时间最多下降 50%，slot 使用量最多下降 15%；这是具体客户工作负载的结果，而不是通用服务等级承诺。
执行层如何减少延迟和 slot 时间
仅靠选择更好的逻辑计划并不足以支撑高并发 Agent。BigQuery 的 advanced runtime 还会在执行层自动选择更合适的物理路径。
增强向量化执行
增强向量化利用 SIMD 指令批量处理数据，并尽量避免重复计算。执行引擎还能直接处理字典编码和游程编码的数据，把向量化与并行算法应用到符合条件的查询阶段。
对于适合这种执行模式的查询，单个阶段可能获得最高 10 倍加速，整体 slot 时间最多减少 40%。这里的限定词“符合条件”很重要：复杂 UDF、外部服务调用或无法向量化的表达式，不应预期得到相同收益。
短查询专用路径
低延迟 BI 和 Agent 工具调用经常执行大量扫描范围较小、逻辑并不复杂的查询。此时，建立分布式执行阶段和数据 shuffle 本身就可能成为主要成本。
BigQuery 会为符合条件的短查询减少执行阶段和数据交换，相当于在可扩展的 MPP 系统中透明地选择更轻量的 SMP 路径。摘要给出的结果包括：短查询 slot 使用量最多降低 10 倍、P99 延迟达到亚秒级，部分客户工作负载的吞吐量提高最多 3 倍。
这类优化对 Agent 尤其重要。单条查询节省几十或几百毫秒看似有限，但乘以每秒数千次工具调用后，会直接影响并发容量、响应时间和总成本。
开放表格式不应成为性能例外
采用 Apache Iceberg 和 Parquet 时，团队往往担心失去原生数仓的自动优化能力。BigQuery 的目标是让原生存储表和 Iceberg 表共享同一套执行层收益，包括：
- 自动下推过滤条件。
- 使用列元数据索引 CMETA 做数据裁剪。
- 通过 page skipping 跳过无关页面。
- 使用异步读取优化 I/O。
- 对符合条件的阶段应用增强向量化。
这意味着开放格式可以保留数据可移植性，同时继续使用 BigQuery 的自动执行优化。不过，表布局、文件数量和分区设计仍然重要。大量过小的 Parquet 文件、低选择性的过滤条件或失控的全表扫描，不会因为底层引擎更智能就自动变成理想工作负载。
可以这样建立 Agent 查询的成本护栏
HBO 本身不要求用户启用或改写查询，但应用层仍应限制单次 Agent 行为的最大扫描成本，并记录可追踪的标签。下面是一段可以改造的 Python 示例。
运行前安装 SDK，并配置 Application Default Credentials：
python -m pip install google-cloud-bigquery
gcloud auth application-default login
将 YOUR_PROJECT.analytics.orders 替换为自己的表名，再运行：
from datetime import date
from google.cloud import bigquery
client = bigquery.Client(project="YOUR_PROJECT")
sql = """
SELECT
customer_id,
SUM(order_total) AS revenue
FROM `YOUR_PROJECT.analytics.orders`
WHERE order_date BETWEEN @start_date AND @end_date
GROUP BY customer_id
ORDER BY revenue DESC
LIMIT 20
"""
job_config = bigquery.QueryJobConfig(
maximum_bytes_billed=10 * 1024**3,
labels={
"workload": "agent",
"tool": "customer_revenue",
},
query_parameters=[
bigquery.ScalarQueryParameter("start_date", "DATE", date(2025, 1, 1)),
bigquery.ScalarQueryParameter("end_date", "DATE", date(2025, 1, 31)),
],
)
rows = client.query(sql, job_config=job_config).result()
for row in rows:
print(row.customer_id, float(row.revenue))
这里有三个值得保留的设计：参数化查询让重复调用具有稳定结构，maximum_bytes_billed 阻止异常请求产生无上限扫描，labels 则让平台团队能区分不同 Agent 和工具的成本。
还可以通过 INFORMATION_SCHEMA 找出最近七天 slot 消耗最高的查询。把区域改成作业所在位置，例如将 region-us 改为 region-eu：
SELECT
creation_time,
job_id,
user_email,
statement_type,
ROUND(total_slot_ms / 1000, 2) AS slot_seconds,
TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS elapsed_ms,
total_bytes_processed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
AND error_result IS NULL
ORDER BY total_slot_ms DESC
LIMIT 50;
自动优化并不意味着不再需要可观测性。更合理的分工是：BigQuery 负责选择和修正执行策略，应用负责限制请求边界，平台团队负责监控延迟、吞吐量和单位业务动作的成本。
Fluid Scaling 让性能收益落到账单上
BigQuery 的计算计量基于实际消耗的 slot-seconds，而不是要求用户长期持有固定数量的节点。增强后的 fluid scaling 按秒扩缩计算资源，使执行时间和 slot 时间的下降能够更直接地反映为成本下降。
摘要给出的平均结果是，自动扩缩工作负载的成本最多降低约 34%。其中一家每天处理超过 1 PB 数据的广告技术公司报告基础设施成本下降 25%，同时提高了 slot 扩展能力和每小时处理吞吐量。
评估这类收益时，应同时观察四个指标：
- P50、P90 和 P99 查询延迟，而不只是平均值。
- 每次业务动作或每次 Agent 任务消耗的 slot-seconds。
- 峰值 QPS 下的排队时间与失败率。
- 自动扩缩后的月度总成本，而不只是单条查询价格。
落地时保留必要的工程边界
BigQuery 的演进说明，Agent 时代的数据平台必须从“提供查询能力”转向“持续管理查询行为”。历史优化、运行时向量化、短查询路径、开放格式裁剪和按秒扩缩共同组成了一套自动调节系统。
团队可以减少人工分析每一条执行计划的时间，但不应取消应用侧治理。上线 Agent 数据访问前，至少应完成以下检查：为查询设置扫描上限；使用参数而不是拼接 SQL；按 Agent、工具和环境添加作业标签；监控尾延迟和 slot 消耗；对生成式 SQL设置表、列与区域白名单；用实际工作负载验证成本，而不是套用公开基准的峰值结果。
真正适合 Agent 的数据平台，不只是偶尔跑出更快的查询，而是能在查询规模持续增长时自动学习、发现回退并控制资源消耗。BigQuery 正在把这些能力下沉到查询处理器本身，让工程团队把精力放在 Agent 的业务决策和用户体验上，而不是追赶不断变化的执行计划。