Configuration des paramètres my.cnf pour obtenir l'optimisation des performances du moteur InnoDB_Mysql

2020-05-21

Sur Internet, j'ai lu d'innombrables configurations de my.cnf, la plupart des configurations mentionnées ne sont rien de plus que celles-ci:

1. innodb_buffer_pool_size
2. innodb_log_file_size
3. innodb_log_buffer_size
4. innodb_flush_log_at_trx_commit

J'ai ensuite écrit deux exemples moi-même, un monothread et un multithread pour tester si les performances ont été améliorées en modifiant les paramètres de configuration. Le résultat est que seul innodb_flush_log_at_trx_commit peut améliorer les performances. Qu'un ou deux des paramètres 1, 2, 3 soient activés ou que trois ajustements simultanés n'aient pas affecté les performances du test. J'y ai pensé, cela peut être dû au fait que la quantité de mes données de test n'est pas assez grande, puis suivez les conditions pour tester ces 3 paramètres avec une plus grande quantité de données.

Voici une description détaillée de innodb_flush_log_at_trx_commit:

Si innodb_flush_log_at_trx_commit est défini sur 0, le tampon de journal sera écrit dans le fichier journal une fois par seconde et l'opération de vidage du fichier journal (vidage sur disque) est effectuée simultanément. Dans ce mode, lorsque la transaction est validée, elle ne déclenchera pas activement l'opération d'écriture sur le disque.
Si innodb_flush_log_at_trx_commit est défini sur 1, MySQL écrit les données du tampon de journal dans le fichier journal à chaque fois que la transaction est validée et est vidée (vidage sur disque).
Si innodb_flush_log_at_trx_commit est défini sur 2, MySQL écrit les données du tampon de journal dans le fichier journal chaque fois que la transaction est validée. Mais l'opération de vidage (vidage sur disque) ne se produit pas en même temps. Dans ce mode, MySQL effectuera une opération de vidage (vidage sur disque) toutes les secondes.

Résultats :

Lorsqu'il est défini sur 0, ce mode est le plus rapide, mais il n'est pas sûr. L'effondrement du processus mysqld entraînera la perte de toutes les données de transaction dans la dernière seconde.
Lorsqu'il est réglé sur 1, ce mode est le moyen le plus sûr, mais aussi le plus lent. Dans le cas d'un crash du service mysqld ou d'un crash de l'hôte du serveur, le journal binaire ne peut perdre au plus qu'une instruction ou une transaction.
Lorsqu'il est défini sur 2, ce mode est plus rapide et plus sûr que 0. Uniquement lorsque le système d'exploitation se bloque ou que le système est hors tension, toutes les données de transaction dans la dernière seconde peuvent être perdues.

Remarque : en raison de la stratégie de planification des processus, cette opération "effectuer un vidage toutes les secondes (vidage sur disque)" n'est pas garantie à 100% "par seconde".

Conclusion : lorsque innodb_flush_log_at_trx_commit est défini sur 0 ou 2, la vitesse est similaire, les deux sont beaucoup plus rapides que lorsqu'elles sont définies sur 1.

Ici, je me rappelle la différence entre les moteurs InnoDB et MyISAM. L'avantage d'InnoDB est qu'il est plus rapide que MyISAM dans le cas d'un traitement simultané. Le nombre de mon pool de threads est défini en fonction du nombre de threads de processeur. Ensuite, j'ai défini le nombre de pools de threads pour être plus grand, plus grand et plus grand que le nombre de threads de processeur. Par conséquent, les performances de mon programme de test se sont à nouveau améliorées et j'étais ivre. Il s'est avéré que ma compréhension du pool de threads était trop superficielle. La taille optimale du pool de threads

www.xd1998.com@2001-2030Partage De Technologie