Pendant le fonctionnement du site d'architecture PHP+MYSQL, souvent, vous rencontrerez divers problèmes de performances, tels que MySQL, PHP, CPU, E/S disque, cache, etc. Parmi eux, le goulot d'étranglement MySQL est le facteur le plus courant et le plus difficile à résoudre qui affecte les performances du site Web. Nous utiliserons généralement Redis, Memcached ; , etc. Les logiciels de mise en cache pour mettre en cache le contenu sont en effet l'une des meilleures solutions, mais ils nécessitent la prise en charge des programmes de sites Web. Cependant, les programmes de sites Web les plus couramment utilisés ne prennent pas en charge ou ne peuvent pas parfaitement prendre en charge ces logiciels de mise en cache. utilisez MySQL pour mettre en cache le contenu. Optimisez les performances de MySQL avec ses propres ajustements de configuration pour atténuer les goulots d'étranglement de MySQL.
Préparation :
1. Pagoda Linux panel version officielle 5.2.0+ (sortie le 20/09/2017) version bêta 5.2.4+
2. MySQL 5.x
Habituellement, nous divisons le réglage de MySQL en les parties suivantes :
1. Le réglage des paramètres de configuration MySQL (doit être ajusté en fonction des conditions de fonctionnement du site Web)
2. Réglage de l'index de la table de données (l'effet est évident, mais généralement d'excellents programmes open source n'ont pas besoin d'être ajustés) 3. Réglage des instructions SQL (c'est ce que font les programmeurs ou les administrateurs de base de données) Aujourd'hui, nous parlons principalement de la façon d'ajuster les paramètres de configuration de MySQL avec les nouvelles fonctionnalités du Pagoda Panel. Regardons d'abord deux images
<.>
Évidemment, (Figure 1) montre l'état d'exécution actuel de MySQL, (Figure 2) montre les principaux paramètres de configuration de MySQL
Interprétons-le ci-dessous. deux images :
1. Nombre de connexions actives/pic (Figure 1) La connexion actuellement active est 1. Depuis le démarrage du service MySQL, le nombre de connexions le plus élevé est de 54 ; est proche ou égal à (Figure 2) Lorsque max_connections est défini, max_connections doit être augmenté de manière appropriée. Il convient de noter que n'augmentez pas trop à la fois. Il est recommandé d'augmenter de 50 à chaque fois et d'observer pendant un certain temps. . Si cela ne suffit pas, continuez à augmenter.
2. Le taux de réussite du cache de threads dans (Figure 1) est de 99,78 %. Si cette valeur est inférieure à 90 %, il est recommandé d'augmenter la taille de thread_cache_size dans (Figure 2). il par 8 à chaque fois.
3. Taux de réussite de l'index (Figure 1) Le taux de réussite de l'index est de 99,50 %. Si cette valeur est inférieure à 95 %, il est recommandé d'augmenter le key_buffer_size dans (Figure 2) de manière appropriée. augmentez-le de 64 à chaque fois. Veuillez expliquer. Oui, si votre base de données utilise le moteur Innodb, vous pouvez ignorer cette option
4. Taux de réussite de l'index Innodb (Figure 1) Le taux de réussite de l'index Innodb est de 100 %. Si cette valeur est inférieure à 95%, il est recommandé de l'utiliser de manière appropriée. Augmentez innodb_buffer_pool_size dans (Figure 2). Il est recommandé de l'augmenter de 64 à chaque fois. , vous pouvez ignorer cette option
5. Taux de réussite du cache de requêtes Le cache de requêtes MySQL est une comparaison Fonction controversée, je recommande personnellement que lorsque vous utilisez un logiciel de mise en cache tel que redis, memcached, etc., vous puissiez l'activer désactivé en définissant query_cache_size sur 0 dans (Figure 2). Lorsque vous n'utilisez pas de logiciel de mise en cache et qu'il y a une utilisation excessive de la mémoire, et lorsque les goulots d'étranglement de la base de données sont évidents, vous pouvez essayer d'activer la mise en cache des requêtes. Il s'agit d'une fonction qui repose fortement sur les données. Optimisation de la structure de la table et des instructions SQL Si la structure de la table de données et les instructions SQL sont optimisées pour la mise en cache des requêtes, l'effet est toujours très bon.
6. Créer des tables temporaires sur le disque (Figure 1) La proportion de création de tables temporaires sur le disque est de 0,42 %, ce qui montre que la plupart des tables temporaires sont créées en mémoire et n'augmenteront pas trop la surcharge des E/S du disque. Il est recommandé que lorsque la proportion est supérieure à 2%, augmentez tmp_cache_size de manière appropriée (Figure 1). Il est recommandé de l'augmenter de 32 à chaque fois. Lorsque la proportion est supérieure à 60%, abandonnez. Les instructions SQL ne sont pas spécifiquement optimisées, donc pendant le fonctionnement, un grand nombre de tables temporaires seront ouvertes et aucune quantité de mise en cache ne suffira.
7. Table ouverte Lorsque la table ouverte dans (Figure 1) est proche ou égale à table_open_cache dans (Figure 2), vous pouvez augmenter table_open_cache de manière appropriée, mais si elle est trop grande, cela peut entraîner votre programme pour interrompre fréquemment les connexions MySQL, il est recommandé de se situer dans les 1024 et le maximum ne doit pas dépasser 2048.
8. Le nombre d'index inutilisés et les montants JOIN inutilisés S'il n'est pas 0, vérifiez l'index du tableau de données, tant qu'il n'augmente pas de façon spectaculaire, par exemple en augmentant de milliers par jour. il peut généralement être ignoré. Après tout, il est plus approprié pour les programmeurs ou les administrateurs de base de données d'optimiser les index.
9. Le nombre de fusions après le tri Si cette valeur augmente lentement, il est recommandé d'augmenter le sort_buffer_size dans (Figure 2) de manière appropriée. Il est recommandé de l'augmenter de 512 à chaque fois, mais le maximum ne doit pas dépasser 8192. Si cette valeur a augmenté rapidement, augmenter sort_buffer_size est inutile, alors abandonnez cette option. Ce blâme devrait être laissé aux développeurs du programme.
10. Nombre de verrous de table Si le serveur a une faible surcharge du processeur et verrouille les tables de manière folle, il est recommandé de convertir toutes les tables de données en innodb et de penser à sauvegarder avant la conversion.
11. Plan d'optimisation Il s'agit d'un plan d'optimisation recommandé que nous donnons en fonction de la taille de la mémoire. Il est uniquement recommandé de l'utiliser pour les valeurs de référence de base. Chaque élément de configuration doit être ajusté en fonction de la situation réelle.
Remarque : Après avoir enregistré la configuration des paramètres, celle-ci ne prendra pas effet immédiatement. N'oubliez pas de redémarrer le service MySQL.