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.

Ajuste de las cargas de trabajo de escritura

La implementación del equilibrio de carga y la liberación de la instancia de escritura ayudarán a que la carga de trabajo de escritura tenga un mejor rendimiento durante los picos de uso. Para lograr un mejor rendimiento de escritura con un alto nivel de simultaneidad, siga estos pasos adicionales.

Mueva la integridad referencial a la capa de aplicación

Si bien las comprobaciones de integridad referencial son importantes, con el hiperescalado podrían ser perjudiciales para su carga. Para cada escritura, se deben realizar escaneos adicionales antes de ejecutar la propia escritura, lo que se traduce en un rendimiento deficiente. Si su aplicación requiere controles de integridad estrictos, inclúyalos en la capa de aplicación para evitar que se limiten las escrituras.

Evite el uso de claves principales pesadas

Mantenga sus claves principales ligeras. El motor de almacenamiento InnoDB anexa la clave principal a todos los demás índices que cree en la tabla. Cuando la clave principal es grande, afecta al tamaño del índice. El almacenamiento y la recuperación de las páginas de datos se ralentizarán si la clave principal es muy grande. Un ejemplo común es el uso de identificadores únicos universales como claves principales. Este no es un buen enfoque si el objetivo es el rendimiento en un entorno hiperescalado.

Use el intercambio de particiones para cargar datos en tablas particionadas

Si va a escribir grandes conjuntos de datos en tablas particionadas, la combinación de CARGAR DATOS DE S3 e intercambio de particiones puede mejorar el rendimiento, ya que las inserciones no acceden a la tabla principal. El intercambio de particiones utiliza un lenguaje de definición de datos (DDL) y bloquea los metadatos de la tabla. Asegúrese de que esto se haga cuando haya pocas consultas o ninguna en ejecución en la tabla, de modo que el DDL del intercambio de particiones pueda obtener el bloqueo de metadatos sin esperas. El intercambio en sí solo tarda unos milisegundos en completarse.

Eliminar los índices que no se utilizan

InnoDB optimiza sus planes de consultas en función del crecimiento de sus datos, y es una buena idea comprobar si hay índices no utilizados en su base de datos y eliminarlos. Los índices no utilizados consumen E/S cuando la aplicación escribe datos en una tabla. Consulte la lista de índices no utilizados y compruebe que no se trata de índices que se utilicen en pocas ocasiones, como en los informes trimestrales. Además, considere que algunos índices se utilizan para garantizar la unicidad o el orden, y también deben tenerse en cuenta.

Asegúrese de que las versiones antiguas de las filas se depuren de manera eficiente

En la implementación InnoDB del control de concurrencia multiversión (MVCC), cuando se modifica un registro, la versión actual (antigua) de los datos que se están modificando se registra primero como deshacer un registro en un registro de anulación de registro. Un valor creciente de longitud de lista de historial (HLL) indica que los subprocesos de recopilación de elementos no utilizados de InnoDB (subprocesos de depuración) no están a la altura de la carga de trabajo de escritura o que la depuración está bloqueada por una consulta o transacción de larga duración. Cuando la recopilación de elementos no utilizados se bloquea o retrasa, la base de datos puede sufrir un retraso de depuración considerable que puede afectar negativamente al rendimiento de las consultas. Puede utilizar los siguientes consejos para optimizar el proceso de depuración.

Asegúrese de que el registro no cause más problemas

El registro de consultas general registra las conexiones y desconexiones de los clientes, así como todas las instrucciones recibidas por el servidor en el orden en que se recibieron. Cuando está activado, el registro es sincrónico, lo que puede suponer una penalización sustancial del rendimiento en un sistema ocupado. A menos que sea necesario, se recomienda desactivar el registro general.

El registro de consultas lentas registra las instrucciones que tardaron más que el número de segundos de ejecución long_query_time, con la configuración predeterminada de 10 segundos. Cuando la configuración se establece en 0, todas las instrucciones se registran de forma sincrónica, lo que puede provocar una penalización del rendimiento en las bases de datos ocupadas.