Escenarios de uso para el Almacén de consultas: Azure Database for PostgreSQL: servidor flexible
SE APLICA A: 
Azure Database for PostgreSQL con servidor flexible
Puede usar Almacén de consultas en una amplia variedad de escenarios en los que sea crítico realizar y un seguimiento y mantener un rendimiento predecible de la carga de trabajo. Considere los siguientes ejemplos:
- Identificación y optimización de las consultas más costosas.
- pruebas A/B.
- Mantener el rendimiento estable durante las actualizaciones.
- Identificación y mejora de las cargas de trabajo improvisadas.
Identificación y optimización de las consultas costosas
Identificación de las consultas de ejecución más prolongada
Use las vistas del Almacén de consultas de la base de datos azure_sys del servidor para identificar rápidamente las consultas de larga duración. Estas consultas suelen consumir la mayoría de recursos. La optimización de las consultas de duración más larga puede mejorar el rendimiento porque se liberan recursos para otras consultas que se ejecutan en el sistema.
Selección de consultas con diferenciales de rendimiento
El Almacén de consultas segmenta los datos de rendimiento en ventanas de tiempo, por lo que puede realizar un seguimiento del rendimiento de una consulta a lo largo del tiempo. Esto ayuda a identificar exactamente qué consultas están contribuyendo a que se produzca el aumento en el tiempo total transcurrido. Como resultado, puede delimitar la solución de problemas de la carga de trabajo.
Ajuste de consultas costosas
Al identificar una consulta con un rendimiento poco óptimo, la acción que realice depende de la naturaleza del problema. Algunas de estas acciones pueden ser:
- Asegúrese de que las estadísticas están actualizadas para las tablas subyacentes utilizadas por la consulta.
- Considere la posibilidad de volver a escribir las consultas costosas. Por ejemplo, aproveche las ventajas de la parametrización de consultas y reduzca el uso de SQL dinámico. Implemente una lógica óptima al leer datos, como aplicar el filtrado de datos en la base de datos, en lugar de hacerlo en el lado de la aplicación.
Pruebas A/B
Use el Almacén de consultas para comparar el rendimiento de la carga de trabajo antes y después de un cambio de aplicación que planea introducir, o antes y después de la migración. Ejemplos de escenarios de uso del Almacén de consultas para evaluar el impacto de los cambios en el rendimiento de la carga de trabajo:
- Migración entre versiones principales de PostgreSQL.
- Implementar una nueva versión de una aplicación.
- Modificar la cantidad de recursos concedidos al servidor.
- Cambiar cualquiera de los parámetros del servidor que afectan al comportamiento del servidor.
- Crear índices que faltan en las tablas a las que hacen referencia las consultas costosas.
- Migración desde un servidor único de Azure Database for PostgreSQL al servidor flexible de Azure Database for PostgreSQL.
En cualquiera de estos escenarios, aplique el flujo de trabajo siguiente:
- Ejecute la carga de trabajo con el Almacén de consultas antes del cambio planeado para generar una línea base de rendimiento.
- Aplique los cambios deseados en un momento controlado en el tiempo.
- Siga ejecutando la carga de trabajo, lo suficientemente largo como para generar la imagen de rendimiento del sistema después del cambio.
- Compare los resultados de antes y después del cambio.
- Decida si desea mantener el cambio o revertirlo.
Identificación y mejora de las cargas de trabajo improvisadas
Algunas cargas de trabajo no tienen consultas dominantes que se puedan optimizar para mejorar el rendimiento general de la aplicación. Esas cargas de trabajo suelen caracterizarse por un número relativamente alto de consultas únicas, cada una de las cuales consumen una parte de los recursos del sistema. Cada consulta única se ejecuta con poca frecuencia, por lo que su consumo en tiempo de ejecución no es crítico. Por otro lado, dado que la aplicación genera nuevas consultas todo el tiempo, una parte significativa de los recursos del sistema se dedica a compilar consultas, lo que no es un proceso óptimo. Normalmente, esta situación se produce si la aplicación genera consultas (en lugar de usar consultas parametrizadas o procedimientos almacenados) o si se basa en marcos de asignación relacional de objetos que generan consultas de forma predeterminada.
Si controla el código de la aplicación, puede considerar la posibilidad de volver a escribir la capa de acceso a datos para usar procedimientos almacenados o consultas parametrizadas. Sin embargo, esta situación también se puede mejorar sin cambios en la aplicación al forzar la parametrización de consulta para toda la base de datos (todas las consultas) o para las plantillas de consulta individuales con el mismo hash de consulta.