[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eOptimizing query performance in BigQuery involves reducing the amount of work a query does, which leads to faster execution, lower resource consumption, and reduced costs.\u003c/p\u003e\n"],["\u003cp\u003eEvaluating query performance in BigQuery includes factors such as input data, communication between nodes, computation, outputs, capacity and concurrency, and query patterns.\u003c/p\u003e\n"],["\u003cp\u003eBigQuery BI Engine can accelerate certain query patterns by using an in-memory analysis service that caches frequently used data, often without requiring query modifications.\u003c/p\u003e\n"],["\u003cp\u003eBigQuery offers on-demand and capacity-based pricing models, with capacity-based pricing providing dedicated query processing capacity and being recommended for consistent monthly expenditures or higher capacity needs.\u003c/p\u003e\n"],["\u003cp\u003eUnderstanding the query plan and timeline generated by BigQuery is critical for query optimization, as it provides execution statistics, stage details, and resource utilization insights.\u003c/p\u003e\n"]]],[],null,["# Introduction to optimizing query performance\n============================================\n\nThis document provides an overview of optimization techniques that can improve\nquery performance in BigQuery. In general, queries that do less work\nperform better. They run faster and consume fewer resources, which can result in\nlower costs and fewer failures.\n\nQuery performance\n-----------------\n\nEvaluating query performance in BigQuery involves several factors:\n\n- [Input data and data sources (I/O)](/bigquery/docs/best-practices-performance-compute#reduce-data-processed): How many bytes does your query read?\n- [Communication between nodes (shuffling)](/bigquery/docs/best-practices-performance-compute#reduce-data-processed): How many bytes does your query pass to the next stage? How many bytes does your query pass to each slot?\n- [Computation](/bigquery/docs/best-practices-performance-compute#optimize-query-operations): How much CPU work does your query require?\n- [Outputs (materialization)](/bigquery/docs/best-practices-performance-compute#reduce-query-output): How many bytes does your query write?\n- [Capacity and concurrency](#capacity-and-concurrency): How many slots are available and how many other queries are running at the same time?\n- [Query patterns](/bigquery/docs/best-practices-performance-patterns): Are your queries following SQL best practices?\n\nTo evaluate specific queries or whether you are experiencing resource contention,\nyou can use [Cloud Monitoring](/bigquery/docs/monitoring) or the [BigQuery administrative resource charts](/bigquery/docs/admin-resource-charts) to monitor how your BigQuery jobs consume\nresources over time. If you identify a slow or resource-intensive query, you can\nfocus your performance optimizations on that query.\n\nSome query patterns, especially those generated by business intelligence tools,\ncan be accelerated by using [BigQuery BI Engine](/bigquery/docs/bi-engine-query).\nBI Engine is a fast, in-memory analysis service that accelerates many\nSQL queries in BigQuery by intelligently caching the data you use\nmost frequently. BI Engine is built into BigQuery,\nwhich means you can often get better performance without any query modifications.\n\nAs with any systems, optimizing for performance sometimes involves tradeoffs.\nFor example, using advanced SQL syntax can sometimes introduce complexity and\nreduce the queries' understandability for people who aren't SQL experts.\nSpending time on micro-optimizations for noncritical workloads could also divert\nresources away from building new features for your applications or from identifying\nmore important optimizations. To help you achieve the highest possible return on\ninvestment, we recommend that you focus your optimizations on the workloads that\nmatter most to your data analytics pipelines.\n\nOptimization for capacity and concurrency\n-----------------------------------------\n\nBigQuery offers two pricing models for queries:\n[on-demand](/bigquery/pricing#on_demand_pricing) pricing and\n[capacity-based](/bigquery/pricing#capacity_compute_analysis_pricing)\npricing. The on-demand model provides a shared pool of capacity, and pricing is\nbased on the amount of data that is processed by each query you run.\n\nThe [capacity-based](/bigquery/docs/reservations-workload-management) model is\nrecommended if you want to budget a consistent, monthly expenditure\nor if you need more capacity than is available with the on-demand model.\nWhen you use capacity-based pricing, you allocate dedicated query processing\ncapacity that is measured in [slots](/bigquery/docs/slots).\nThe cost of all bytes processed is included in the capacity-based price.\nIn addition to fixed [slot commitments](/bigquery/docs/reservations-workload-management#slot_commitments),\nyou can use [autoscaling slots](/bigquery/docs/slots-autoscaling-intro),\nwhich provide dynamic capacity based on your query workload.\n\nThe performance of queries that are run repeatedly on the same data can vary,\nand the variation is generally larger for queries using on-demand slots than\nit is for queries using slot reservations.\n\nDuring SQL query processing, BigQuery breaks down the\ncomputational capacity required to execute each stage of a query into\nslots. BigQuery automatically determines the\nnumber of queries that can run concurrently as follows:\n\n- On-demand model: number of slots available in the project\n- Capacity-based model: number of slots available in the reservation\n\nQueries that require more slots than are available are [queued](/bigquery/docs/query-queues)\nuntil processing resources become available. After a query begins execution,\nBigQuery calculates how many slots each query stage\nuses based on the stage size and complexity and the number of slots\navailable. BigQuery uses a technique called [fair scheduling](/bigquery/docs/slots#fair_scheduling_in_bigquery)\nto ensure that each query has enough capacity to progress.\n\nAccess to more slots doesn't always result in faster performance for a query. However, a\nlarger pool of slots can improve the performance of large or complex\nqueries, and the performance of highly concurrent workloads. To\nimprove query performance, you can [modify your slot reservations](/bigquery/docs/reservations-tasks)\nor set a higher limit for [slots autoscaling](/bigquery/docs/slots-autoscaling-intro).\n\nQuery plan and timeline\n-----------------------\n\nBigQuery generates a [query plan](/bigquery/query-plan-explanation) each time that you run a query.\nUnderstanding this plan is critical for effective query optimization.\nThe query plan includes execution statistics such as bytes read and slot time\nconsumed. The query plan also includes details about the different stages of execution, which can help you\ndiagnose and improve query performance. The [query execution graph](/bigquery/docs/query-insights)\nprovides a graphical interface for viewing the query plan and diagnosing query performance issues.\n\nYou can also use the [`jobs.get` API method](/bigquery/docs/reference/rest/v2/jobs/get)\nor the [`INFORMATION_SCHEMA.JOBS` view](/bigquery/docs/information-schema-jobs)\nto retrieve the query plan and timeline information. This information is used by\n[BigQuery Visualiser](https://github.com/GoogleCloudPlatform/professional-services/tree/master/tools/bq-visualizer),\nan open source tool that visually represents the flow of execution stages in a\nBigQuery job.\n\nWhen BigQuery executes a query job, it converts the declarative\nSQL statement into a graph of execution. This graph is broken up into a series\nof query stages, which themselves are composed of more granular sets of\nexecution steps. BigQuery uses a heavily distributed parallel\narchitecture to run these queries. The BigQuery stages model the\nunits of work that\nmany potential workers might execute in parallel. Stages communicate with one\nanother through a\n[fast, distributed shuffle architecture](/blog/products/gcp/in-memory-query-execution-in-google-bigquery).\n\nIn addition to the query plan, query jobs also expose a timeline of execution.\nThis timeline provides an accounting of units of work completed, pending, and\nactive within query workers. A query might have multiple stages with active\nworkers simultaneously, so the timeline is intended to show overall progress of\nthe query.\n\nTo estimate how computationally expensive a query is, you can look at the\ntotal number of slot seconds the query consumes. The lower the number of slot\nseconds, the better, because it means more resources are available to other\nqueries running in the same project at the same time.\n\nThe query plan and timeline statistics can help you understand how\nBigQuery executes queries and if certain stages dominate resource\nutilization. For example, a `JOIN` stage that generates far more output rows than\ninput rows might indicate an opportunity to filter earlier in the query.\nHowever, the managed nature of the service limits whether some details are\ndirectly actionable. For best practices and techniques to improve query\nexecution and performance, see\n[Optimize query computation](/bigquery/docs/best-practices-performance-compute).\n\nWhat's next\n-----------\n\n- Learn how to troubleshoot query execution issues using the [BigQuery audit logs](/bigquery/docs/reference/auditlogs).\n- Learn other [cost-controlling techniques](/bigquery/docs/controlling-costs) for BigQuery.\n- View near real-time metadata about BigQuery jobs using the [`INFORMATION_SHEMA.JOBS` view](/bigquery/docs/information-schema-jobs).\n- Learn how to monitor your BigQuery usage using the [BigQuery System Tables Reports](https://github.com/GoogleCloudPlatform/bigquery-utils/tree/master/dashboards/system_tables)."]]