A BigQuery query is slow. What do you check first?
Why A is the answer
The query plan, and how much data it scans
The query plan and the amount of data scanned show where a slow query spends its time.
In detail
- The query plan shows how much data is scanned, and where time goes.
- Fix the largest stage first.
Use case
An illustrative scenario, not a real incident.
A query slows down, and its plan shows a full table scan with a costly join.
See it in different ways
stateDiagram-v2 [*] --> QueryPlan QueryPlan --> PartitionAndCluster: scans too much QueryPlan --> MaterializedView: repeated aggregation QueryPlan --> BiEngine: dashboards need sub-second PartitionAndCluster --> [*] MaterializedView --> [*] BiEngine --> [*]
flowchart LR S0["Open the plan"] --> S1["Check bytes scanned"] --> S2["Find the slow stage"] --> S3["Fix it"]
Key point: Start with the query plan.
Why the other options are wrong
- B. The dataset's default table expiry
- Expiry has no effect on speed.
- C. The BI tool's cache setting
- A BI cache does not explain the query itself.
- D. The analyst's IAM role
- A role has no effect on speed.