Debugging in BigQuery means inspecting execution plans, cost estimates, and job metadata with EXPLAIN, EXPLAIN ANALYZE, dry runs, and INFORMATION_SCHEMA views.
Start with EXPLAIN
to view the logical and distributed execution plan. The plan highlights stage count, read volume, and shuffle size so you can spot expensive joins or scans quickly.
Append OPTION (dry_run=TRUE)
or use the CLI flag --dry_run
.BigQuery parses the statement, shows the bytes it will read, and skips execution, keeping your bill safe.
Use EXPLAIN ANALYZE
after a query finishes.It reruns the statement, captures stage-level timings, shuffle sizes, and slot utilization, then returns a detailed JSON plan.
start_time, end_time, slots_allocated, shuffle_output_bytes, and wait_ratio_avg reveal parallelism and bottlenecks.
Query region-us.INFORMATION_SCHEMA.JOBS_BY_USER
to list your last 1,000 jobs with text, status, total_slot_ms, and error messages. Filter by creation_time
to find problematic runs fast.
Join JOBS_TIMELINE
with JOBS_BY_JOB
on job_id
.Stage durations, pending ratios, and shuffles point to skewed joins, missing partitions, or blown-up cross joins.
Check the EXPLAIN plan for distributedStageCount
.High shuffle or bytes spilled to temp suggest adding filters earlier, using clustered tables, or breaking the query into smaller steps.
2 Keep result sets small with LIMIT
during tests.2 Materialize subqueries to temp tables for isolated inspection.2 Add ORDER BY NULL
when ordering is unnecessary.2 Always compare dry-run bytes before and after changes.
.
Yes. Use job history views. JOBS_BY_JOB
stores the execution plan and statistics of completed jobs, so you can inspect them later without re-execution.
It reruns your query, so you pay for the additional slot time and bytes processed. Use it only after narrowing the problem with EXPLAIN or dry runs.
Click "Query Plan" in the BigQuery UI and copy the JSON. Or save the JSON returned by EXPLAIN ANALYZE into Galaxy Collections for collaborative review.