Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Guía para ajustar las consultas
Después de identificar las consultas problemáticas en su carga de trabajo, debe ajustar cada consulta. Use las siguientes directrices de ajuste para ayudar a que su carga de trabajo se ejecute de manera más eficiente.
Minimice el número de filas escaneadas
Por básico que parezca, este es un gran consejo a considerar cuando se ajustan las consultas. Use la instrucción EXPLAIN y revise la columna de filas para ver cuántas filas escanea el optimizador en cada unión. Intente reducir el número de filas escaneadas al crear un índice óptimo y, a continuación, vuelva a explicar la consulta para confirmar su trabajo. Para obtener más información, consulte la documentación de MySQL
Si utiliza tablas particionadas, consúltelas siempre con la cláusula WHERE, que permite reducir las particiones para que el optimizador no tenga que escanear cada partición. Si la cláusula WHERE contiene una constante para la columna particionada, el optimizador sabrá qué partición buscar, lo que hace que la consulta sea más eficaz.
Otra faceta de este consejo es el diseño de la base de datos. Cuantas menos tablas haya en la consulta, más rápida será la consulta. Si puede desnormalizar el diseño de la base de datos, logrará que el optimizador escanee menos filas, lo que se traduce en un rendimiento de consulta más rápido.
Minimice el uso de tablas temporales y de tablas temporales en el disco
El optimizador de Aurora MySQL-Compatible crea tablas temporales tanto en la RAM como en el disco si no puede obtener los resultados deseados de la consulta directamente de los índices. Por lo tanto, una gran parte del ajuste consiste en disponer de los índices correctos que se adapten a su carga de trabajo. Sin embargo, es posible que haya consultas en la carga de trabajo que no puedan basarse únicamente en los índices, por lo que algunas operaciones pueden realizarse en un archivo temporal. Esto está bien siempre y cuando los mantenga al mínimo y se asegure de que se creen muy pocas tablas en el disco. MySQL crea tablas en el disco cuando el tamaño de la tabla temporal es demasiado grande para guardarla en la memoria. La lógica que utiliza MySQL para comprobar el tamaño de la tabla temporal interna es el menor de los dos valores variables tmp_table_size y. max-heap-table-size Puede ajustar estas variables a un valor óptimo en función de su carga de trabajo, de modo que, en los casos en que no pueda evitar las tablas temporales, las coloque en el disco solo en pocas ocasiones.
Puede evitar también los tipos de archivos
Si su carga de trabajo tiene muchas consultas ORDER BY, la mejor forma de resolverlas es utilizar los índices correctos en las tablas. Asegúrese de que los índices de varias columnas estén bien diseñados para evitar que se clasifiquen en archivos. No se puede ordenar una columna si las columnas anteriores no están escaneadas con constantes (in, >, <, != y BETWEEN no permitirán ordenar en la siguiente columna a la derecha). La forma óptima de ordenar en MySQL es colocar un índice de varias columnas que ubique las columnas que contienen valores constantes en la consulta a la izquierda de la columna de clasificación en una estructura contigua. Si, como último recurso, la consulta no puede devolver resultados sin ordenar los archivos, mueva la clasificación a la aplicación.
Evite ejecutar consultas de agregación con un alto nivel de simultaneidad
Es posible que su carga de trabajo tenga un número reducido de consultas de agregación para atender algunas funciones de la aplicación. Este caso de uso requiere mucha cautela. El motor InnoDB está diseñado para soportar cargas de procesamiento de transacciones en línea (OLTP) adecuadas, pero incluso unas cuantas consultas agrupadas por grupos con una alta simultaneidad pueden suponer una gran carga para la CPU y perjudicar rápidamente el rendimiento del clúster. Para resolver los casos de uso en los que se requieren conjuntos de resultados agregados, agregue previamente los datos en tablas listas para su lectura, para evitar por completo las consultas agrupadas por grupos.
Pruebe la simultaneidad de las consultas
Al ajustar consultas individuales, recuerde que estas consultas se ejecutan simultáneamente en varios v CPUs en Aurora compatible con MySQL. La consulta puede ejecutarse en unos pocos milisegundos en el entorno de prueba en ejecuciones únicas. Pero este no es el panorama completo. Asegúrese de probar la consulta con el nivel de simultaneidad esperado en su clúster de producción y compare su rendimiento. Lance la consulta a producción solo cuando cumpla sus objetivos de simultaneidad. Asegúrese de utilizar el optimizador hint sql_no_cache en sus scripts de prueba para evitar recuperar los resultados de la caché. Puede utilizar herramientas como mysqlslap para realizar la prueba de forma simultánea y comparar los resultados.
