Quelles options de configuration pour MySQL offrent les améliorations de vitesse les plus importantes?

Quelles options de configuration pour MySQL offrent les améliorations de vitesse les plus importantes?

Je m'interroge sur les améliorations réelles du fichier de configuration, les types de table, les configurations matérielles, la réplication, etc. Tout autre chose que la structure de requête et la structure de table (elles sont faciles à trouver sur le site Web et Stack Overflow). Des éléments tels que les paramètres du cache de requêtes vous ont-ils donné le plus de vitesse? Que diriez-vous des lecteurs; est-il préférable de l'avoir sur un RAID externe ou interne? La réplication vous a-t-elle donné de meilleures performances, en particulier avec les grandes requêtes en lecture?

Quels autres paramètres / modifications avez-vous effectués pour améliorer les performances de MySQL?

Remarque: Je me rends compte que cela dépend beaucoup de l'utilisation (c'est-à-dire, petit site Web vs entrepôt de données), mais comme je pense que la plupart d'entre nous travaillent probablement sur une variété de sites / systèmes, il est bon de connaître une variété de techniques qui peuvent s'appliquer à différents situations. De plus, je pense que certaines techniques peuvent être transférées d'une situation à l'autre.

Voici mes recommandations (votre millage peut varier)

• Utilisez un RAID matériel. Cela va à l'encontre de mes recommandations d'utiliser le RAID logiciel dans d'autres publications, mais c'est une situation spécifique où vous voulez la carte RAID matérielle. Plus précisément, vous voulez que la NVRAM alimentée par batterie sur la carte RAID réduise le temps nécessaire pour que le fichier journal fsync soit stocké sur le disque.
• Utilisez UNIQUEMENT des volumes RAID 1 ou RAID 10. Le coût des écritures RAID 5 ou 6 est trop élevé pour être toléré dans une charge de travail mixte lecture / écriture.
• Utilisez des LUN distincts pour les volumes de données, de journaux et de tmp. Ceux-ci doivent tous être séparés des volumes OS et swap.
• Utilisez InnoDB .
• Utilisez innodb_file_per_table
• Utilisez un système d'exploitation 64 bits
• Réglez votre pool de mémoire tampon InnoDB sur ~ 80% de votre RAM disponible
• Définissez vos fichiers journaux sur 1/4 de la taille de votre pool de mémoire tampon, vous entre 2 et 4 fichiers journaux. Des fichiers journaux plus volumineux signifient des temps d'arrêt et de récupération plus lents, mais vous permettent de restaurer des vidages de base de données plus rapidement.
• log_slow_queries, log-queries-not-using-indexes, set-variable = long_query_time = 1, examinez chaque requête dans ce journal, refactorisez votre schéma pour éviter les analyses de table et les tables tmp dans la mesure du possible.

Encore une fois, Dave Cheney l'a vraiment sorti du parc ici. Je ne peux vraiment rien ajouter à sa réponse à votre question. Cependant, j'aimerais souligner ce que vous n'avez pas demandé. Comme Jeremy Zawodny et Peter Zaitsev m'ont appris il y a des années, votre retour sur investissement pour le temps passé à rechercher et à optimiser les mauvaises requêtes va surpasser votre retour sur investissement pour le temps passé à effectuer des changements de configuration 10 fois. Bien sûr, vous ne voulez pas avoir une mauvaise configuration, une mauvaise configuration RAID ou une RAM insuffisante. Mais, parmi les excellentes et même marginales, les mauvaises requêtes des DBA MySQL (généralement des développeurs / frameworks, pas du DBA) sont une condition chronique , où une mauvaise configuration est supportable .

(J'ai creusé pour ces adjectifs pendant un certain temps et je ne suis toujours pas satisfait de ceux que j'ai choisis.)

Je tiens à souligner à nouveau que si vos développeurs utilisent un ORM comme ceux courants dans les frameworks comme Ruby on Rails et Django, vous DEVEZ VRAIMENT surveiller les requêtes qui frappent votre base de données. Lorsque les développeurs arrêtent de penser à SQL et laissent la base de données s'abstraire, vraiment méchant ce fluage. J'adore les deux frameworks que je viens de mentionner. (Ne me votez pas pour de mauvaises paroles.) Cela rend simplement Query Sleuthing très important. (Lire: Sécurité d'emploi)

Peu d'autres choses (qui n'ont pas été mentionnées dans la réponse de Dave Cheney)

• Essayez de définir innodb_flush_method sur O_DIRECT pour éviter la double mise en mémoire tampon des données. Évitez cela si votre carte RAID n'a pas de cache d'écriture sauvegardé par batterie ou si vos données sont sur un SAN.

• Jouez également avec la innodb_thread_concurrency. Je crois que la valeur par défaut est 8, mais cela vaut la peine de l'ajuster pour voir si cela améliore les performances

• Assurez-vous que le cache de requêtes est activé et vérifiez les statistiques pour voir quel est le taux de succès. Si c'est bon, essayez de l'augmenter pour voir si cela améliore le taux de réussite.

• Selon les applications exécutées, vous pourrez peut-être modifier le niveau d'isolement par défaut. La valeur par défaut est REPEATABLE_READ mais READ_COMMITTED peut vous donner de meilleures performances

• Si vos instructions sont principalement des mises à jour et des suppressions, vous pouvez essayer d'amorcer le cache sur l'esclave en effectuant une requête SELECT qui renvoie le jeu de résultats à modifier. Découvrez l' outil mk-slave-prefetch qui le fera pour vous

• Jetez un œil à d'autres moteurs de stockage en dehors de MyISAM et InnoDB

Je ne peux rien dire sur le matériel, mais vous pouvez essayer http://blog.mysqltuner.com . C'est un script Perl qui analyse vos paramètres MySQL.

Vous pouvez voir un exemple de sortie sur http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

La première chose générale à faire est de regarder les paramètres de la mémoire. Les paramètres par défaut pour MySQL sont très très conservateurs. Quel que soit le moteur que vous utilisez, vous devrez probablement augmenter un certain nombre de paramètres de mémoire par dix ou même par cent.

La prochaine chose que vous devez faire est de regarder le cache de la table. La valeur par défaut est 64, ce qui n'est utile que si vous n'avez pas plus d'environ 60 tableaux. Vous voudrez soulever cela très loin.

La troisième chose à faire est de regarder les paramètres de thread et de connexion. Le délai d'attente par défaut est extrêmement long pour la plupart des applications Web et peut être réduit à quelque chose comme 30 secondes. Cela améliorera également l'utilisation de la mémoire, car MySQL récoltera les connexions plus tôt, laissant beaucoup moins traîner dans un état de «sommeil».