Las sentencias SQL lentas en una instancia de ApsaraDB RDS for MySQL suelen originarse por alguna de estas causas: problemas de esquema o índices, agotamiento de recursos, efectos secundarios tras actualizar la versión, parámetros mal configurados, saturación de caché (cache stampede), operaciones por lotes pesadas, transacciones sin cerrar o tareas programadas. Cada causa presenta síntomas distintos y cuenta con su respectiva solución.
Enfoque para la solución de problemas
Antes de investigar cualquier causa específica, comience por el monitoreo. Siga esta secuencia:
Descarte primero los cuellos de botella de recursos antes de analizar causas particulares. Abra Monitoring and Alerts en la consola de ApsaraDB RDS y consulte la pestaña Standard Monitoring. Haga clic en Resource Monitoring para revisar el uso de CPU, el uso de memoria, el uso de disco, las IOPS (operaciones de entrada/salida por segundo), las conexiones, la proporción de aciertos de caché, las consultas por segundo (QPS) y las transacciones por segundo (TPS). Si alguna de estas métricas se mantiene alta de forma constante, es probable que la lentitud se deba a un cuello de botella de recursos y no a una sentencia SQL específica. Para más detalles, consulte los límites de instancia.
Si alguna métrica está cerca del 100 %, comience por revisar los límites de instancia o las operaciones por lotes.
Si las métricas parecen normales pero las consultas siguen siendo lentas, revise las transacciones sin cerrar y las excepciones de SQL.
-
Abra SQL Explorer and Audit para identificar las sentencias lentas específicas. Dos métricas le ayudarán a priorizar cuáles atender primero:
Tiempo de ejecución: las consultas que se ejecutan durante mucho tiempo retienen bloqueos por más tiempo y obstaculizan otras operaciones. Resuelva estas primero.
Número de ejecuciones: las consultas que se ejecutan con frecuencia generan una carga acumulada alta, incluso si cada ejecución individual es rápida. Estas son excelentes candidatas para optimización.
Solución de problemas de sentencias SQL lentas causadas por límites de instancia
Causas
Una instancia alcanza su límite de rendimiento por varias razones:
La carga de trabajo crece sin un aumento correspondiente en la capacidad de almacenamiento o en los recursos de cómputo.
El host físico envejece y degrada el rendimiento general de la instancia.
El volumen de datos aumenta y los cambios en la estructura de datos ralentizan ciertas sentencias SQL con el paso del tiempo.
Cómo identificarlo
En la consola de ApsaraDB RDS, vaya a Monitoring and Alerts en el panel de navegación. En la pestaña Standard Monitoring, haga clic en Resource Monitoring y compruebe si todas las métricas de uso de recursos están cerca del 100 %. De ser así, la instancia alcanzó su límite de rendimiento.
Solución
Use SysBench para medir el rendimiento máximo de su instancia. Los valores de QPS y TPS obtenidos con SysBench representan el límite superior, incluso bajo cargas de trabajo con consultas complejas. Para conocer los procedimientos de evaluación, consulte Test guidelines.
Si la instancia alcanzó su límite de rendimiento, actualice a una especificación superior. Para más detalles, consulte Change instance specifications.
Solución de problemas de sentencias SQL lentas causadas por excepciones de SQL
Causas
Las excepciones de SQL ocurren cuando las consultas son inherentemente ineficientes debido a problemas en el diseño del esquema, índices faltantes o una cantidad excesivamente grande de filas que se deben escanear.
Cómo identificarlo
En la consola de ApsaraDB RDS, vaya a SQL Explorer and Audit en el panel de navegación. Revise el tiempo de ejecución y el número de ejecuciones de cada sentencia SQL lenta para determinar qué consultas requieren atención.
Solución
Optimice las sentencias SQL problemáticas según sus requisitos de negocio. Para más detalles, consulte SQL optimization.
Solución de problemas de sentencias SQL lentas causadas por actualizaciones de versión
Causas
Actualizar una instancia de RDS puede modificar los planes de consulta de las sentencias SQL existentes. Los planes de consulta de MySQL usan tipos de unión (join) cuya eficiencia varía. En orden descendente de eficiencia: system, const, eq_ref, ref, fulltext, ref_or_null, index_merge, unique_subquery, index_subquery, range, index y all. Para más detalles, consulte la documentación oficial de MySQL.
Cuando el plan de consulta de una sentencia muy utilizada cambia a un tipo de unión menos eficiente (como range o index), la sentencia se ejecuta más lentamente. Si muchas de estas sentencias se paralelizan al mismo tiempo, los hilos se acumulan más rápido de lo que se liberan. Esto agota el pool de conexiones y afecta todas las cargas de trabajo de la instancia.
Cómo identificarlo
En la consola de ApsaraDB RDS, vaya a Monitoring and Alerts en el panel de navegación. En la pestaña Standard Monitoring, haga clic en Resource Monitoring y compruebe el número de conexiones activas. Un aumento repentino de conexiones después de una actualización es un indicador claro.
Solución
Use EXPLAIN para analizar los planes de consulta de las sentencias lentas. Identifique los tipos de unión, el uso de índices y el número de filas escaneadas para cada sentencia. Con base en este análisis, reconstruya las sentencias SQL o ajuste los índices para restaurar la eficiencia de las consultas. Para más detalles, consulte SQL optimization.
Solución de problemas de sentencias SQL lentas causadas por parámetros inadecuados
Causas
Los valores incorrectos en los parámetros innodb_buffer_pool_instances y join_buffer_size pueden degradar el rendimiento de ejecución de SQL.
Cómo identificarlo
En la consola de ApsaraDB RDS, vaya a Parameters en el panel de navegación. En la pestaña Edit History, revise el historial de reconfiguración de estos parámetros para comprobar si algún cambio reciente coincide con la degradación del rendimiento.
Solución
Reconfigure innodb_buffer_pool_instances y join_buffer_size con valores adecuados para su carga de trabajo y las especificaciones de su instancia.
Solución de problemas de sentencias SQL lentas causadas por la expiración de entradas en caché
Causas
Cuando varias entradas de la caché expiran al mismo tiempo (fenómeno conocido como cache stampede), un gran volumen de solicitudes omite la caché y llega directamente a la base de datos. ApsaraDB RDS no garantiza una proporción de aciertos de caché del 100 %, por lo que este escenario es posible bajo alta concurrencia.
Cómo identificarlo
En la consola de ApsaraDB RDS, vaya a Monitoring and Alerts en el panel de navegación. En la pestaña Standard Monitoring, haga clic en Resource Monitoring y revise la proporción de aciertos de caché junto con QPS y TPS. Una caída repentina en la proporción de aciertos combinada con un aumento en QPS indica una saturación de caché.
Solución
Habilite las siguientes funciones para manejar el incremento de carga y reducir el impacto de los fallos de caché:
Thread Pool: gestiona la concurrencia de conexiones y evita el agotamiento de hilos. Consulte Thread pool.
Fast query cache: almacena en caché los resultados de las consultas para evitar cálculos repetidos. Consulte Fast query cache.
Automatic SQL throttling: limita la tasa de solicitudes SQL entrantes para proteger la instancia. Consulte Automatic SQL throttling.
Solución de problemas de sentencias SQL lentas causadas por operaciones por lotes
Causas
Las importaciones, eliminaciones o consultas masivas de datos que se ejecutan de forma simultánea con las cargas de trabajo normales compiten por los recursos de E/S de disco y de transacciones. Esto ralentiza toda la ejecución de SQL.
Cómo identificarlo
Revise el uso de disco, los registros de SQL o las estadísticas de consultas lentas. Una señal útil es el tamaño de los archivos de registro binario (binlog), que normalmente es de 500 MB cada uno. Si un archivo binlog supera los 500 MB, investigue si una operación por lotes es la causa.
En la consola de ApsaraDB RDS, vaya a Monitoring and Alerts en el panel de navegación. En la pestaña Standard Monitoring, haga clic en Resource Monitoring para revisar el uso de disco y las IOPS. Haga clic en Engine Monitoring para revisar las TPS.
Solución
Programe las operaciones por lotes fuera del horario de mayor demanda. Si esto no es posible, divida cada operación por lotes en solicitudes más pequeñas y envíelas de forma secuencial para reducir la carga máxima.
Solución de problemas de sentencias SQL lentas causadas por transacciones sin cerrar
Causas
Las transacciones sin cerrar retienen bloqueos e impiden la ejecución de otras consultas. Las consultas afectadas se acumulan en la cola, aparecen como sentencias SQL lentas y provocan que aumente el número de sesiones activas.
Cómo identificarlo
Si una carga de trabajo se vuelve lenta de repente, pero el uso de CPU y las IOPS permanecen normales mientras el número de sesiones activas sigue aumentando, es probable que existan transacciones sin cerrar. Esto suele ocurrir cuando se ejecutan sentencias SQL manualmente a través de Data Management Service (DMS) o fuera de los flujos normales de la aplicación.
Solución
Identifique las transacciones que retienen bloqueos. Compruebe si hay conflictos de bloqueo entre transacciones y luego finalice las sentencias SQL que generan el bloqueo para liberarlos.
Solución de problemas de sentencias SQL lentas causadas por tareas programadas
Causas
Las tareas programadas que realizan escrituras o actualizaciones por lotes se ejecutan en intervalos fijos. Aunque estén configuradas para correr fuera del horario de mayor demanda, pueden competir con otras cargas de trabajo debido a los bloqueos y la presión de E/S. Esto genera sentencias SQL lentas durante el periodo de superposición.
Cómo identificarlo
Si la carga de la instancia aumenta en intervalos regulares y predecibles, es probable que intervengan tareas programadas. Revise la información de monitoreo en la pestaña Standard Monitoring de la página Monitoring and Alerts para relacionar los patrones de carga con los horarios de las tareas.
Solución
Ajuste la programación para que las tareas se ejecuten durante los periodos de menor tráfico. Espacie varias tareas programadas para evitar que sus picos de carga se superpongan.
Solución de problemas de sentencias SQL lentas causadas por problemas de red
Si tanto las métricas de recursos como el análisis de sentencias SQL parecen normales, pero la carga de trabajo sigue siendo lenta, compruebe el método de conexión de red. En la página de detalles de la instancia, vaya a Database Connection para consultar el tipo de endpoint. Los endpoints públicos tienen mayor latencia que los endpoints privados (VPC). Si su aplicación se ejecuta en una instancia de ECS dentro de la misma VPC que su instancia de RDS, use el endpoint privado para conectarse; esto reduce la latencia de red. Para más detalles, consulte Solución de problemas de fallos de conexión a una instancia.
Pasos siguientes
Utilice las siguientes herramientas y temas para investigar más a fondo las sentencias SQL lentas: