Protección del diccionario de datos
Intente utilizar un motor de almacenamiento que admita el bloqueo a nivel de fila, como InnoDB. Utilice únicamente motores de almacenamiento con bloqueo a nivel de tabla (como aplicaciones de almacenamiento de datos) en escenarios en los que haya muchas más operaciones de lectura que de escritura. operaciones, como MyISAM.
2. Reducir la posibilidad de bloqueos de ganancia en caliente para evitar la exclusión mutua global tanto como sea posible.
Las áreas críticas (recursos a los que solo se puede acceder mediante un único subproceso) pueden reducir gravemente la concurrencia de un sistema MySQL; los grupos de búfer de InnoDB y los diccionarios de datos son áreas críticas comunes. Afortunadamente, la nueva versión de InnoDB ha podido funcionar bien en procesadores multinúcleo y admite el establecimiento de múltiples instancias de grupo de búfer utilizando la variable de servidor innodb_buffer_pool_instances. Cada instancia del grupo de búfer administra su propia lista libre, actualización de lista, LRU y otras estructuras de datos relacionadas con el grupo de búfer, y está protegida por su propio mutex.
3. Ejecutar múltiples subprocesos de E/S en paralelo.
Aumentar el número de subprocesos de E/S del disco a través de la variable del servidor innodb_io_capacity puede mejorar el rendimiento de las operaciones de front-end (como SELECT), pero el número de subprocesos de E/S del disco no debe exceder las IOPS. del disco (las IOPS de hardware único a 7200 rpm suelen ser de alrededor de 100).
Además, la E/S asíncrona también puede mejorar la concurrencia del sistema hasta cierto punto. En los sistemas Linux, InnoDB puede utilizar el subsistema de E/S asíncrono de Linux estableciendo el valor de la variable del servidor MySQL innodb_use_native_aio en ON.
4. Tareas de back-end paralelas
De forma predeterminada, la operación de limpieza de MySQL (utilizada para eliminar registros marcados para su eliminación) la completa el hilo principal de InnoDB, lo que puede reducir la probabilidad de recursos internos. de contención, mejorando así la escalabilidad del servicio MySQL. Sin embargo, a medida que se intensificó la competencia dentro de InnoDB, los beneficios de rendimiento de esta configuración fueron casi insignificantes. Por lo tanto, al activar la variable del servidor innodb_purge_threads, el hilo principal debe ejecutarse por separado del hilo de purga en el entorno de producción.
5. El hilo SQL en el modelo de replicación de un solo hilo es un punto caliente.
Ejecutar múltiples subprocesos SQL en paralelo en el servidor esclavo puede mejorar efectivamente el rendimiento del servidor esclavo MySQL. MySQL 5.6 admite replicación multiproceso (un subproceso de replicación para cada biblioteca);