En esta página, se explica cómo detectar cambios en la velocidad de ejecución de las consultas, inspeccionar los planes de ejecución de consultas y especificar un índice diferente para las consultas futuras si es necesario.
Obtén el perfil detallado de una consulta en formato JSON con la API de REST
De forma predeterminada, cuando ejecutas una consulta, la API devuelve solo los resultados de la sentencia.
Esto se debe a que queryMode está configurado como NORMAL. Para incluir estadísticas de ejecución detalladas con los resultados de la consulta, establece queryMode en PROFILE.
Crea una sesión
Antes de actualizar el modo de consulta, crea una sesión, que representa un canal de comunicación con el servicio de base de datos de Spanner.
- Ve a la página
projects.instances.databases.sessions.create. Proporciona el ID del proyecto, el ID de la instancia y el ID de la base de datos en el siguiente formato:
projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_IDHaz clic en Ejecutar. La respuesta muestra la sesión que creaste con este formato:
projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_IDUsa esta sesión para generar un perfil de la consulta en el siguiente paso. Una sesión permanece activa durante un máximo de una hora entre usos consecutivos antes de que Spanner la borre.
Para obtener más información sobre cómo usar las sesiones, consulta Sesiones.
Crea un perfil de la consulta
Habilita el modo PROFILE para la consulta.
- Ve a la página
projects.instances.databases.sessions.executeSql. En session, ingresa el ID de sesión que creaste en Crea una sesión:
projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_IDEn el cuerpo de la solicitud, usa lo siguiente:
{ "sql": "SQL_QUERY", "queryMode": "PROFILE" }Haz clic en Ejecutar. La respuesta incluye los resultados de la consulta, el plan de consulta y las estadísticas de ejecución de la consulta.
Soluciona problemas de uso de índices
Cuando usas consultas en SQL para buscar datos, Spanner utiliza automáticamente cualquier índice secundario que pueda recuperar los datos de manera más eficiente. Sin embargo, en algunos casos, Spanner puede elegir un índice que haga que las consultas sean más lentas. Como resultado, es posible que notes que algunas consultas se ejecutan más lento de lo esperado.
Detecta cambios en la velocidad de ejecución de las consultas
Es muy probable que veas un cambio en la velocidad de ejecución de las consultas después de realizar alguno de estos cambios:
- Cambiar de forma significativa una gran cantidad de datos existentes que tienen un índice secundario.
- Agregar, cambiar o descartar un índice secundario.
Puedes usar varias herramientas diferentes para identificar una consulta específica que Spanner ejecuta con más lentitud de lo habitual:
- Estadísticas de consultas y Estadísticas de consultas.
Métricas específicas de la aplicación que capturas y analizas con Cloud Monitoring. Por ejemplo, puedes supervisar la métrica Recuento de consultas para determinar la cantidad de consultas en una instancia a lo largo del tiempo y averiguar qué versión del optimizador de consultas se usó para ejecutar una consulta.
Herramientas de supervisión del cliente que miden el rendimiento de tu aplicación.
Estadísticas del optimizador para las bases de datos recién creadas
Cuando consultas bases de datos recién creadas con datos recién insertados o importados, es posible que Spanner no seleccione los índices más adecuados, ya que el optimizador de consultas tarda hasta tres días en recopilar estadísticas automáticamente. Para optimizar el uso del índice de una base de datos nueva de Spanner antes de ese momento, puedes crear un paquete de estadísticas nuevo de forma manual.
Revisa el esquema
Después de encontrar la consulta que se ralentizó, observa la instrucción de SQL de la consulta y, luego, identifica las tablas que usa la sentencia y las columnas que recupera de esas tablas.
A continuación, busca los índices secundarios que existen para esas tablas. Determina si alguno de los índices incluye las columnas que consultas, lo que significa que Spanner podría usar uno de los índices para procesar la consulta.
- Si hay índices aplicables, el siguiente paso es encontrar el índice que Spanner usó para la consulta.
Si no hay índices aplicables, usa el comando
gcloud spanner operations listpara verificar si borraste un índice aplicable recientemente:gcloud spanner operations list \ --instance=INSTANCE \ --database=DATABASE \ --filter="@TYPE:UpdateDatabaseDdlMetadata"Si descartaste un índice aplicable, el cambio tal vez afectó el rendimiento de la consulta. Vuelve a agregar el índice secundario a la tabla. Después de que Spanner agregue el índice, vuelve a ejecutar la consulta y observa su rendimiento. Si el rendimiento no mejora, el siguiente paso es encontrar el índice que Spanner usó para la consulta.
Si no descartaste un índice aplicable, entonces la selección del índice no hizo que el rendimiento de la consulta empeorara. Busca otros cambios en tus datos o patrones de uso que podrían haber afectado el rendimiento.
Encuentra el índice que se usó para una consulta
Para averiguar qué índice usa Spanner para procesar una consulta, visualiza el plan de ejecución de consultas en la consola de Google Cloud :
Ve a la página Instancias de Spanner en la Google Cloud consola.
Haz clic sobre el nombre de la instancia que deseas consultar.
En el menú de navegación, selecciona la base de datos que deseas consultar y, luego, haz clic en Spanner Studio.
Ingresa la consulta que deseas probar.
En el menú Ejecutar consulta, selecciona Solo explicación. Spanner muestra el plan de consulta.
Busca al menos uno de los operadores siguientes en el plan de consultas:
- Análisis de tabla
- Análisis del índice
- Aplicación cruzada o aplicación distribuida cruzada
En las siguientes secciones, se explica el significado de cada operador.
Operador de análisis de tabla
El operador table scan indica que Spanner no usó un índice secundario:
Por ejemplo, supongamos que la tabla Albums no tiene ningún índice secundario y ejecutas la consulta siguiente:
SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");
Debido a que no hay índices para usar, el plan de consultas incluye un operador de análisis de tabla.
Operador de análisis del índice
El operador index scan indica que Spanner usó un índice secundario cuando procesó la consulta:
Por ejemplo, supongamos que agregas un índice a la tabla Albums:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Luego, ejecuta la consulta siguiente:
SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");
El índice AlbumsByAlbumTitle contiene AlbumTitle, que es la única columna que selecciona la consulta. Como resultado, el plan de consultas incluye un operador de análisis del índice.
Operador de aplicación cruzada
En algunos casos, Spanner usa un índice que contiene solo algunas de las columnas que selecciona la consulta. Como resultado, Spanner debe unir el índice con la tabla base.
Cuando se produce este tipo de unión, el plan de consulta incluye un operador de aplicación cruzada o aplicación cruzada distribuida que tiene las siguientes entradas:
- Un operador de análisis del índice para el índice de una tabla
- Un operador de análisis de tabla para la tabla que posee el índice
Por ejemplo, supongamos que agregas un índice a la tabla Albums:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Luego, ejecuta la consulta siguiente:
SELECT * FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");
El índice AlbumsByAlbumTitle contiene AlbumTitle, pero la consulta selecciona todas las columnas de la tabla, no solo AlbumTitle. Como resultado, el plan de consultas incluye un operador de aplicación distribuida cruzada, con un análisis del índice de AlbumsByAlbumTitle y un análisis de tabla de Albums como sus entradas.
Elige un índice diferente
Después de encontrar el índice que Spanner usó para tu consulta, intenta
ejecutarla con un índice diferente o analiza la tabla base en lugar
de usar un índice. Para especificar el índice, agrega una directiva FORCE_INDEX a la consulta.
Si encuentras una versión más rápida de la consulta, actualiza tu aplicación para usar esa versión.
Lineamientos para elegir un índice
Usa estos lineamientos a fin de decidir qué índice probar para la consulta:
Si tu consulta cumple con alguno de estos criterios, intenta usar la tabla base en lugar de un índice secundario:
- La consulta verifica la igualdad con un prefijo de la clave primaria de la tabla base (por ejemplo,
SELECT * FROM Albums WHERE SingerId = 1). - Una gran cantidad de filas satisfacen los predicados de consulta (por ejemplo,
SELECT * FROM Albums WHERE AlbumTitle != "There Is No Album With This Title"). - La consulta usa una tabla base que contiene solo cientos de filas.
- La consulta verifica la igualdad con un prefijo de la clave primaria de la tabla base (por ejemplo,
Si la consulta contiene un predicado muy selectivo (por ejemplo,
REGEXP_CONTAINS,STARTS_WITH,<,<=,>,>=o!=), intenta usar un índice que incluya las mismas columnas que usas en el predicado.
Prueba la consulta actualizada
Usa la consola de Google Cloud para probar la consulta actualizada y averiguar cuánto tiempo lleva procesarla.
Si tu consulta incluye parámetros de consulta y uno de ellos está vinculado a algunos valores mucho más que otros, vincula el parámetro de consulta a uno de esos valores en tus pruebas. Por ejemplo, si la consulta incluye un predicado como WHERE country = @countryId y casi todas tus consultas vinculan @countryId al valor US, entonces vincula @countryId a US para tus pruebas de rendimiento. Con este enfoque, optimizas las consultas que ejecutas con más frecuencia.
Para probar la consulta actualizada en la consola de Google Cloud , sigue estos pasos:
Ve a la página Instancias de Spanner en la Google Cloud consola.
Haz clic sobre el nombre de la instancia que deseas consultar.
En el menú de navegación, haz clic en la base de datos que deseas consultar y, luego, en Spanner Studio.
Ingresa la consulta que deseas probar, incluida la directiva
FORCE_INDEX, y haz clic en Ejecutar consulta.La consola de Google Cloud abre la pestaña Tabla de resultados y, luego, muestra los resultados de la consulta, incluido el tiempo que tardó el servicio de Spanner en procesar la consulta.
Esta métrica no incluye otras fuentes de latencia, como el tiempo que tardó la consola de Google Cloud en interpretar y mostrar los resultados de la consulta.
Limitación de consultas
Durante la ejecución de la consulta, Spanner puede limitar las consultas en varios lugares.
Tiempo de espera del cliente y Demora de la cola del servidor son las dos métricas de limitación principales.
Tiempo de espera del cliente
El tiempo de espera del cliente representa la cantidad de tiempo que el cliente de Spanner espera a que la aplicación consuma los resultados. Esto indica que el cliente no puede procesar los resultados tan rápido como Spanner los produce. Para resolver este problema, aumenta el rendimiento de la aplicación consumidora o almacena en búfer todos los resultados en la aplicación cliente y procésalos después de que se complete la consulta.
Retraso de la cola del servidor
La demora en la cola del servidor se produce cuando el servidor de procesamiento demora la programación de la ejecución de la consulta. En el panel Resumen de la consulta, verifica la métrica Demora de la cola del servidor. Si la métrica no está presente, no se produjo ninguna demora del servidor.
Esta demora puede indicar que los servidores que ejecutan la consulta están sobrecargados. Para verificar si existe un hotspot, consulta Busca hotspots en tu base de datos. Para solucionar problemas de hotspots, consulta Soluciona problemas de hotspots con estadísticas de división en caliente.
Datos modificados recientemente
Los cambios en los datos de la tabla pueden afectar el rendimiento de las consultas.
Paquete de estadísticas desactualizado
Si el optimizador usa un paquete de estadísticas inactivo, es posible que elija un plan
subóptimo. En la sección Resumen de la consulta, puedes consultar el paquete de estadísticas.
Si el paquete está inactivo o falta, ejecuta
ANALYZE
para asegurarte de que las estadísticas del optimizador estén actualizadas.

Para obtener más información, consulta Paquetes de estadísticas.
Cambios en el contenido de la tabla
El rendimiento de las consultas depende de los datos que procesa la consulta. La mejor manera de abordar un problema de rendimiento de las consultas depende de cómo cambiaron los datos:
- Sesgo en la distribución de valores: El paquete de estadísticas captura este sesgo, pero el optimizador de consultas solo puede usar esta información cuando usas valores literales en la consulta.
- Cambio grande en el recuento de filas: Evalúa si los predicados filtran las filas de forma suficiente a medida que aumenta el tamaño de la tabla.
- Sesgo en el tamaño del valor: El sesgo en el tamaño de los valores es problemático junto con los predicados escalares costosos (por ejemplo, realizar un predicado
LIKEen un valorSTRINGque contiene cadenas grandes).
Para obtener más información sobre la ejecución de consultas, usa la API de REST.