Múltiples instancias de una base de datos Aurora MySQL. Solo una de ellas no utiliza el índice posible.
Me encontré con un problema de rendimiento con una consulta grande y la descompongo usando el comando explain. El entorno de desarrollo y el de producción están bien, pero la base de datos de control de calidad (QA) está teniendo problemas.
Aquí tienes un explain modificado para que no revele información confidencial:
EXPLAIN SELECT COUNT(*)
FROM table1 t1
LEFT OUTER JOIN table2 t2 ON t2.correlation_id = t1.correlation_id
WHERE t2.request_id = '<varchar(100) aquí="">';
En una instancia de la base de datos de desarrollo, obtengo lo siguiente:
select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, extra
SIMPLE, t2, , ref, request_id, request_id, 1022, const, 3753, 100, Using where
SIMPLE, t1, , eq_ref, "correlationIdUniqueConstraint, idx_correlation_id", correlationIdUniqueConstraint, 402, dev_db.t2.correlation_id, 1, 100, Using index
La producción es muy similar o idéntica. Por lo tanto, todo parece estar bien hasta ahora.
Sin embargo, en la base de datos de control de calidad (QA), obtengo lo siguiente:
select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, extra
SIMPLE, t2, , ref, request_id, request_id, 1022, const, 1176, 100, <null>
SIMPLE, t1, , ALL, "correlationIdUniqueConstraint, idx_correlation_id", , , , 3271577, 10, Range checked for each record (index map: 0x40000004)
Utilicé la herramienta de comparación de esquemas en DataGrip para hacer que las bases de datos de desarrollo y control de calidad (QA) sean iguales. La única diferencia serían las filas / recuentos exactos. Sin embargo, en términos de filas, Producción > QA > Desarrollo y, sin embargo, Producción y Desarrollo están bien.
Información del esquema relevante:
request_idcuenta con un índice.correlation_ides una cadena de caracteres (varchar) de longitud 100 tanto ent1como ent2.- La restricción de unicidad y el índice de
correlation_idexisten ent1.
Confirmé con la siguiente consulta:
SELECT CHAR_LENGTH(correlation_id)
FROM merchant_analysis
WHERE CHAR_LENGTH(correlation_id) > 90;
Que no hay correlation_id que excedan los 90 caracteres, y mucho menos 100.
Información de la base de datos:
- Versión de MySQL Aurora 5.7.2.07.2
- Memoria RAM de QA y producción > Memoria RAM de desarrollo
Espero que alguien haya tenido un problema similar antes y no tenga que recrear la base de datos de control de calidad (QA).</varchar(100)>
davy.ai
Análisis del problema de rendimiento con una consulta larga
Un experto en TI especializado en mysql, base de datos, amazon-aurora, e índices de bases de datos se enfrentó a un problema de rendimiento con una consulta larga en la base de datos de QA. El experto dividió la consulta con la ayuda de
EXPLAINy descubrió que en la base de datos de QA la consulta era diferente a la de las instancias de desarrollo y producción.A continuación se muestra el declaración se
EXPLAINanonimizada utilizada para analizar la consulta:En la instancia de desarrollo y la instancia de producción, la salida de la declaración
EXPLAINparecía estar bien. Sin embargo, en la base de datos de QA, el experto encontró que la declaraciónEXPLAINmostraba problemas de rendimiento.El experto utilizó la herramienta de comparación de esquemas en Datagrip para igualar las bases de datos de Desarrollo y QA, y aparte de las filas y recuentos exactos, no hubo otras diferencias. Sin embargo, el problema persistió y no parecía haber IDs de correlación que superaran los 100 caracteres ni siquiera los 90 caracteres.
A continuación se presentan algunos datos relevantes del esquema y la base de datos:
request_idtiene un índice.correlation_ides varchar(100) en ambas tablas.correlation_idexisten entabla1.El experto espera encontrar una solución sin tener que recrear la base de datos de QA.