Use query insights to improve query performance

Stay organized with collections Save and categorize content based on your preferences.

This page describes how to use the Query insights dashboard to detect and analyze performance problems with your queries.

Introduction

Query insights helps you detect, diagnose, and prevent query performance problems for Cloud SQL databases. It supports intuitive monitoring and provides diagnostic information that helps you go beyond detection to identify the root cause of performance problems.

With query insights, you can monitor performance at an application level and trace the source of a problematic query across the application stack by model, view, controller, route, user, and host. The query insights tool can integrate with your existing application monitoring (APM) tools and Google Cloud services by using open standards and APIs. This way, you can monitor and troubleshoot query problems by using your favorite tool.

Query insights helps you improve Cloud SQL query performance by guiding you through the following steps:

• View the database load for top queries
• Identify a potentially problematic query or tag
• Examine the query or tag to identify issues
• Trace the source of the problem

Query insights for Cloud SQL Enterprise Plus edition

If you're using Cloud SQL Enterprise Plus edition, then you can access additional capabilities in query insights to perform advanced query performance diagnostics. In addition to the standard capabilities of the Query insights dashboard, query insights for Cloud SQL Enterprise Plus edition lets you do the following:

• Capture and analyze wait events for all executed queries.
• Filter aggregated database load by additional dimensions such as queries, tags, wait event types, and more.
• Capture query plans for all executed queries.
• Sample up to 200 query plans per minute.
• Capture longer query text up to 100 KB.
• Obtain near real-time updates for metrics (in the order of seconds).
• Maintain a longer 30-day retention of metrics.
• Obtain index recommendations from index advisor.
• Terminate a session or long-running transaction in active queries.
• Access AI-assisted troubleshooting (Preview).

The following table compares functional requirements and capabilities of query insights for Cloud SQL Enterprise edition with query insights for Cloud SQL Enterprise Plus edition.

Enable query insights for Cloud SQL Enterprise Plus edition

To enable query insights for Cloud SQL Enterprise Plus edition, select Enable Enterprise Plus features when you Enable query insights on your Cloud SQL Enterprise Plus edition instance.

Pricing

There's no additional cost for query insights on Cloud SQL Enterprise edition or Cloud SQL Enterprise Plus edition instances.

Storage requirements

Query insights for Cloud SQL Enterprise edition doesn't occupy any storage space in your Cloud SQL instance storage space. Metrics are stored in Cloud Monitoring. For API requests, see Cloud Monitoring Pricing. Cloud Monitoring has a tier that you can use at no additional cost.

Query insights for Cloud SQL Enterprise Plus edition stores metrics data on the same disk attached to your Cloud SQL instance and requires that you keep the automatic storage increases setting enabled.

Before you begin

Before you use query insights, do the following.

1. Add required roles and permissions.
2. Enable the Cloud Trace API.
3. If you're using Query insights for Cloud SQL Enterprise Plus edition, then make sure that Enable automatic storage increases is enabled for the instance.

Required roles and permissions

To use query insights, you need to grant a predefined role, create a custom role, or provide a user account with the required Identity and Access Management permissions.

For more information about granting roles, see Manage access.

To get the permissions that you need to access historical query execution data in the Query insights dashboard, ask your administrator to grant you the following IAM roles on the project that hosts the Cloud SQL instance:

• Database Insights Monitoring Viewer (roles/databaseinsights.monitoringViewer)
• Cloud SQL Viewer (roles/cloudsql.viewer)

For more information about granting roles, see Manage access to projects, folders, and organizations.

These predefined roles contain the permissions required to access historical query execution data in the Query insights dashboard. To see the exact permissions that are required, expand the Required permissions section:

You might also be able to get these permissions with custom roles or other predefined roles.

• Cloud SQL Editor (roles/cloudsql.editor)
• Cloud SQL Admin (roles/cloudsql.admin)

Enable the Trace API

To view query plans and their end-to-end views, your Google Cloud project must have the Trace API enabled. This setting lets your Google Cloud project receive trace data from authenticated sources at no additional cost. This data can help you detect and diagnose performance issues in your instance.

To confirm that the Trace API is enabled, follow these steps:

1. From the Google Cloud console, go to APIs and Services:

   Go to APIs and Services

2. Click Enable APIs and Services.
3. In the search bar, enter Trace API.
4. If API enabled is displayed, then this API is enabled and there's nothing for you to do. Otherwise, click Enable.

Enable automatic storage increases

If you're using query insights for Cloud SQL Enterprise Plus edition, then make sure that the instance setting to enable automatic storage increases remains enabled. By default, this option is enabled for Cloud SQL instances.

If you previously disabled this instance setting and want to enable query insights for Cloud SQL Enterprise Plus edition, then re-enable automatic storage increases first. You can't turn off automatic storage increases and enable query insights for Cloud SQL Enterprise Plus edition.

Enable query insights

When you enable query insights, all other operations are temporarily suspended. These operations include health checks, logging, monitoring, and other instance operations.

gcloudsqlinstancespatchINSTANCE_ID\--insights-config-query-insights-enabled 

gcloudsqlinstancespatchINSTANCE_ID\ --insights-config-query-insights-enabled\ --insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH\ --query_plans_per_minute=QUERY_PLANS_PER_MINUTE\ --insights-config-record-application-tags\ --insights-config-record-client-address\ --tier=API_TIER_STRING\ --region=REGION

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

 { "settings" : { "insightsConfig" : { "queryInsightsEnabled" : true, "recordClientAddress" : true, "recordApplicationTags" : true, "queryStringLength" : 1024, "queryPlansPerMinute" : 20, } } } 

curl -X PATCH \
 -H "Authorization: Bearer $(gcloud auth print-access-token)" \
 -H "Content-Type: application/json; charset=utf-8" \
 -d @request.json \
 "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
 -Method PATCH `
 -Headers $headers `
 -ContentType: "application/json; charset=utf-8" `
 -InFile request.json `
 -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

 { "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID", "status": "PENDING", "user": "user@example.com", "insertTime": "2025-03-28T22:43:40.009Z", "operationType": "UPDATE", "name": "OPERATION_ID", "targetId": "INSTANCE_ID", "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID", "targetProject": "PROJECT_ID" } 

resource"google_sql_database_instance""INSTANCE_NAME"{name="INSTANCE_NAME"database_version="POSTGRESQL_VERSION"region="REGION"root_password="PASSWORD"deletion_protection=false# set to true to prevent destruction of the resourcesettings{tier="DB_TIER"insights_config{query_insights_enabled=truequery_string_length=2048# Optionalrecord_application_tags=true# Optionalrecord_client_address=true# Optionalquery_plans_per_minute=10# Optional}}}

Metrics are expected to be available in query insights within minutes of query completion. Review the Cloud Monitoring data retention policy.

Query insights traces are stored in Cloud Trace. Review the Cloud Trace data retention policy.

View the Query insights dashboard

The Query insights dashboard shows the query load based on factors that you select. Query load is a measurement of the total work for all the queries in the instance in the selected time range. The dashboard provides a series of filters that help you view query load.

To open the Query insights dashboard, follow these steps:

1. To open the Overview page of an instance, click the instance name.
2. In the Cloud SQL navigation menu, click Query insights, or click Go to Query insights for more in-depth info on queries and performance on the Instance overview page.

The Query insights dashboard opens. Depending on whether you're using query insights for Cloud SQL Enterprise edition or query insights for Cloud SQL Enterprise Plus edition, the Query insights dashboard shows the following information about your instance:

Cloud SQL Enterprise Plus edition

• All queries: Shows database load for all queries for the selected time range. Each query is individually color-coded. To view a point in time for a specific query, hold the pointer over the chart for the query.
• Database: Filters query load on a specific database or all databases.
• User: Filters query load from a specific user account.
• Client address: Filters query load from a specific IP address.
• Time range: Filters query load by time ranges, such as 1 hour, 6 hours, 1 day, 7 days, 30 days, or a custom range.
• Wait event types: Filters query load by CPU and Lock wait event types.
• Queries, Wait event types, Databases, Users, Tags, and Client addresses: Sort by the top dimensions that contribute the most to database load in the chart. See Filter the database load.

Cloud SQL Enterprise edition

• Database: Filters query load on a specific database or all databases.
• User: Filters query load from a specific user account.
• Client address: Filters query load from a specific IP address.
• Time range: Filters query load by time ranges, such as 1 hour, 6 hours, 1 day, 7 days, 30 days, or a custom range.
• Database load graph: Displays the query load graph, based on filtered data.
• CPU capacity, CPU and CPU wait, IO wait, and Lock wait: Filters loads based on the options that you select. See View the database load for top queries for details about each of these filters.
• Queries and Tags: Filters query load by either a selected query or a selected SQL query tag. See Filter the database load.

View the database load for all queries

Database query load is a measure of the work (in CPU seconds) that the executed queries in your selected database perform over time. Each running query is either using or waiting for CPU resources, IO resources, or lock resources. Database query load is the ratio of the amount of time taken by all the queries that are completed in a given time window to the wall-clock time.

The top-level query insights dashboard shows the Database load — all top queries graph. Drop-down menus on the dashboard let you filter the graph for a specific database, user, or client address.

Cloud SQL Enterprise Plus edition

Cloud SQL Enterprise edition

Colored lines in the graph show the query load, split into categories:

• CPU capacity: The number of CPUs available on the instance.
• CPU and CPU Wait: The ratio of the time taken by queries in an active state to wall-clock time. IO and Lock waits don't block queries that are in an active state. This metric might mean that the query is either using the CPU or waiting for the Linux scheduler to schedule the server process running the query while other processes are using the CPU.
• IO Wait: The ratio of time taken by queries that are waiting for IO to wall-clock time. IO wait includes Read IO Wait and Write IO Wait. If you want a breakdown of information for IO waits, you can see it in Cloud Monitoring. See Cloud SQL metrics for more information. For more information, see the PostgreSQL event table.
• Lock Wait: The ratio of time taken by queries that are waiting for Locks to wall-clock time. It includes Lock Waits, LwLock Waits, and Buffer pin Lock waits. To see a breakdown of information for lock waits, use Cloud Monitoring. See Cloud SQL metrics for more information.

Colored lines in the graph show per database load by execution time. Review the graph and use the filtering options to explore these questions:

• Is the query load high? Is the graph spiking or elevated over time? If you don't see a high load, then the problem isn't with your query.
• How long has the load been high? Is it high only now or has it been high for a long time? Use the range selector to select various time periods to find out how long the problem has lasted. Zoom in to view a time window where query load spikes are observed. Zoom out to view up to one week of the timeline.
• What's causing the high load? You can select options to examine the CPU capacity, CPU and CPU wait, Lock wait, or IO wait. The graph for each of these options is a different color so that you can spot the one with the highest load. The dark blue line on the graph shows the maximum CPU capacity of the system. It lets you compare the query load with the maximum CPU system capacity. This comparison helps you determine whether an instance is running out of CPU resources.
• Which database is experiencing the load? Select different databases from the Databases drop-down menu to find the databases with the highest loads.
• Do specific users or IP addresses cause higher loads? Select different users and addresses from the drop-down menus to identify the ones that are causing higher loads.

Filter the database load

• All queries

• Wait event types

• Wait events

• Databases

• Users

• Tags

• Client addresses

To customize the database load chart, select a dimension from the Database Load by execution time drop-down.

View the top contributors to database load

To view the top contributors to the database load, you can use the Top dimensions by database load table. The Top dimensions by database load table displays the top contributors for the time period and dimension that you select in the Database Load by execution time chart drop-down. You can modify the time period or dimension to view the top contributors for a different dimension or time period.

In the Top dimensions by data load table, you can select the following tabs.

Filter by queries

The Top queries table provides an overview of the queries that cause the most query load. The table shows all the normalized queries for the time range and options selected on the Query insights dashboard. It sorts queries by the total execution time during the time range that you selected.

Cloud SQL Enterprise Plus edition

To sort the table, select a column heading.

Cloud SQL Enterprise edition

To sort the table, select a column heading or a property from Filter queries.

The table shows the following properties:

• Query: the normalized query string. By default, query insights shows only 1024 characters in the query string. Queries labeled UTILITY COMMAND usually include BEGIN, COMMIT, and EXPLAIN commands or wrapper commands.
• Database: the database against which the query was run.
• Recommendations: the suggested recommendations, such as Create indexes, to improve query performance.
• Load by total time/Load by CPU/Load by IO wait/Load by lock wait: The options by which you can filter specific queries to find the largest load.
• % load by Queries: The percentage load by individual query.
• Analyze latency: if you enabled AI-assisted troubleshooting (Preview) for this instance, then you can click this link to troubleshoot slow queries.
• Avg execution time (ms): the average time for the query to execute.
• Times called: the number of times the application called the query.
• Avg rows returned: the average number of rows returned for the query.

Query insights stores and displays only normalized queries.

By default, query insights doesn't collect IP addresses or tag information. You can enable query insights to collect this information and, when required, disable collection.

Query plan traces don't collect or store any constant values and removes any PII information that the constant might show.

For PostgreSQL 9.6 and 10, query insights displays normalized queries, that is, ? replaces the literal constant value. In the following example, the name constant is removed and ? replaces it.

UPDATE"demo_customer"SET"customer_id"=?::uuid,"name"=?,"address"=?,"rating"=?,"balance"=?,"current_city"=?,"current_location"=?WHERE"demo_customer"."id"=?

For PostgreSQL version 11 and later, $1, $2, and similar variables replace literal constant values.

UPDATE"demo_customer"SET"customer_id"=$1::uuid,"name"=$2,"address"=$3,"rating"=$4,"balance"=$5,"current_city"=$6,"current_location"=$7WHERE"demo_customer"."id"=$8

Filter by query tags

To troubleshoot an application, you must first add tags to your SQL queries. Query load tags provide a breakdown of the query load of the selected tag over time.

Query insights provides application-centric monitoring to diagnose performance problems for applications built using ORMs. If you're responsible for the entire application stack, query insights provides query monitoring from an application view. Query tagging helps you find issues at higher-level constructs, such as with the business logic or a microservice.

You might tag queries by the business logic, for example, the payment, inventory, business analytics, or shipping tags. You can then find the query load that the various business logic create. For example, you might observe unexpected events, such as spikes for a business analytics tag at 1 PM or unexpected growth for a payment service trending over the previous week.

To calculate the Database load for tag, query insights uses the amount of time taken by every query that uses the tag that you select. The tool calculates the completion time at the minute boundary by using wall-clock time.

On the query insights dashboard, to view the tags table, select Tags. The table sorts tags by their total load by total time.

You can sort the table by selecting a property from Filter tags, or by clicking a column heading. The table shows the following properties:

• Action, Controller, Framework, Route, Application, DB driver: Each property that you added to your queries appears as a column. At least one of these properties must be added if you want to filter by tags.
• Load by total time/Load by CPU/Load by IO wait/Load by lock wait: Options to filter specific queries to find the largest load for each option.
• Avg execution time (ms): The average time for the query to run.
• Avg rows returned: The average number of rows returned for the query.
• Times called: The number of times the application called the query.
• Database: The database against which the query was run.

View query details for a specific query or tag

To determine whether a specific query or tag is the root cause of the problem, do the following from the Queries tab or Tags tab, respectively:

1. To sort the list in descending order, click the Load by total time header.
2. Click the query or tag at the top of the list. It has the highest load and is taking more time than the others.

The Query details page opens and shows the details of the selected query or tag.

Examine a specific query load

The Query details page for a selected query appears as follows:

The Database load — specific query graph shows a measure of the work (in CPU seconds) that your normalized query has performed in your selected query over time. To calculate load, it uses the amount of time taken by the normalized queries that are completed at the minute boundary to the wall-clock time. At the top of the table, the first 1024 characters of the normalized query, with literals removed for aggregation and PII reasons, are displayed.

As with the total queries graph, you can filter the load for a specific query by Database, User, and Client address. Query load is split into CPU capacity, CPU and CPU wait, IO wait, and Lock wait.

Examine a specific tagged query load

The dashboard for a selected tag appears as follows. For example, if all queries from a microservices payment are tagged as payment, you can see the amount of query load that's trending by viewing the tag payment.

The Database load — specific tags graph shows a measure of the work (in CPU seconds) that queries matching your selected tags have performed in your selected database over time. As with the total queries graph, you can filter the load for a specific tag by Database, User, and Client address.

Examine operations in a sampled query plan

A query plan takes a sample of your query and breaks it down into individual operations. It explains and analyzes each operation in the query.

The Query plan samples graph shows all the query plans running at particular times and the amount of time each plan took to run. You can change the rate at which query plan samples are captured per minute. See Enable Query Insights.

By default, the panel on the right shows the details for the sample query plan that takes the longest time, as visible on the Query plan samples graph. To see the details for another sample query plan, click the relevant circle on the graph. Expanded details show a model of all the operations in the query plan.

Each operation shows the latency, rows returned, and the cost of the operation. When you select an operation, you can see more details, such as shared hit blocks, the type of schema, loops, and plan rows.

Try to narrow down the problem by looking into the following questions:

1. What's the resource consumption?
2. How does it relate to other queries?
3. Does consumption change over time?

Examine latency

Latency is the time taken for the normalized query to complete, in wall-clock time. You use the Latency graph to examine latency on the query or tag. The latency dashboard shows the 50th, 95th, and 99th percentile latencies to find outlier behaviors.

The following image shows the database load graph at the 50th percentile for a specific query with filters selected for CPU capacity, CPU and CPU wait, IO wait, and Lock wait.

The latency of parallel queries is measured in wall-clock time even though the query load can be higher for the query due to multiple cores being used to run part of the query.

Try to narrow down the problem by looking into the following questions:

• What's causing the high load? Select options to look at the CPU capacity, CPU and CPU wait, I/O wait, or Lock wait.
• How long has the load been high? Is it only high now? Or has it been high for a long time? Change the time range to find the date and time that the load started performing poorly.
• Were there spikes in latency? Change the time window to study the historical latency for the normalized query.

Trace the source of the problem

When you find the areas and times where the load was the highest, identify the source of the problem by using tracing to drill down further.

To help you identify the specific source of the problem, such as a model, view, controller, route, host, or user, query insights provides an in-context end-to-end application trace view. This view helps you understand what's going on at the Database Layer for a specific request and to find the source of a problematic query by model, view, controllers, and route.

If you enable OpenCensus or OpenTelemetry, opencensus span information is sent to the database along with the tag information inside SQL comments. Any traces from the application to Cloud Logging are linked with database query plan traces to help identify the source of the problem.

Click the End to end tab in the Sample Query screen to look at the in-context trace.

To determine the client and user causing the problem, use the Top client addresses and Top users tables to find the highest loads. You can add a user or IP address to the filter to further analyze a specific user or client address. The details in the tables include the percentage of the query load, the average execution time in milliseconds, and the times called.

You can use Cloud Trace to see end-to-end tracing for each step in the query plan. On the query insights dashboard, click the View in trace link to open the Cloud Trace tool. The trace graph shows all the traces that have been run for the selected period.

For details, see Finding and viewing traces.

Add tags to SQL queries

Tagging SQL queries simplifies application troubleshooting. You can use sqlcommenter to add tags to your SQL queries either automatically or manually.

Use sqlcommenter with ORM

When you use ORM instead of directly writing SQL queries, you might not find application code that's causing performance challenges. You might also have trouble analyzing how your application code affects query performance. To tackle this issue, Query Insights provides an open source library called sqlcommenter. This library is useful for developers and administrators using ORM tools to detect which application code is causing performance problems.

If you're using ORM and sqlcommenter together, the tags are automatically created. You don't need to add or change code in your application.

You can install sqlcommenter on the application server. The instrumentation library allows application information related to your MVC framework to be propagated to the database along with the queries as a SQL comment. The database picks up these tags and starts recording and aggregating statistics by tags, which are orthogonal to statistics aggregated by normalized queries. Query insights shows the tags so that you know which application is causing the query load and can find the application code that's causing performance problems.

When you examine results in SQL database logs, they appear as follows:

SELECT*fromUSERS/action='run+this', controller='foo%3', traceparent='00-01', tracestate='rojo%2'/ 

Supported tags include the controller name, route, framework, and action.

The set of ORM tools in sqlcommenter is supported for the following programming languages:

For more information about sqlcommenter and how to use it in your ORM framework, see the sqlcommenter documentation.

Use sqlcommenter to add tags

If you're not using ORM, you must manually add sqlcommenter tags or comments in the correct SQL comment format to your SQL query. You must also augment each SQL statement with a comment containing a serialized key-value pair. Use at least one of the following keys:

• action=''
• controller=''
• framework=''
• route=''
• application=''
• db driver=''

Query insights drops all other keys.

Disable query insights

gcloudsqlinstancespatchINSTANCE_ID\--no-insights-config-query-insights-enabled

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

 { "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } } } 

curl -X PATCH \
 -H "Authorization: Bearer $(gcloud auth print-access-token)" \
 -H "Content-Type: application/json; charset=utf-8" \
 -d @request.json \
 "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
 -Method PATCH `
 -Headers $headers `
 -ContentType: "application/json; charset=utf-8" `
 -InFile request.json `
 -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

 { "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id", "status": "PENDING", "user": "user@example.com", "insertTime": "2021-01-28T22:43:40.009Z", "operationType": "UPDATE", "name": "operation-id", "targetId": "instance-id", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id", "targetProject": "project-id" } 

Disable query insights for Cloud SQL Enterprise Plus edition

To disable query insights for Cloud SQL Enterprise Plus edition, do the following:

1. In the Google Cloud console, go to the Cloud SQL Instances page.

   Go to Cloud SQL Instances

2. To open the Overview page of an instance, click the instance name.
3. Click Edit.
4. In the Customize your instance section, expand Query insights.
5. Clear the Enable Enterprise Plus features checkbox.
6. Click Save.

What's next

• Launch blog: Solve database bottlenecks faster with the latest query insights for Cloud SQL Enterprise Plus edition
• See Cloud SQL metrics. The query insights metric type strings start with database/postgresql/insights.
• Blog: Boost your query performance troubleshooting skills with Cloud SQL Insights
• Video: Introducing Cloud SQL Insights
• Podcast: Cloud SQL Insights
• Insights Codelab
• Optimize high CPU usage
• Optimize high memory usage
• Blog: Introducing Sqlcommenter: An open source ORM auto-instrumentation library
• Blog: Enable query tagging with Sqlcommenter