Rien de catastophique, mais il faudras faire plus que modifier le fichier de conf.
Tu ne caches rien parce que le résultat de tes requêtes est trop gros.
Dans le cadre de traitement batch, cela peut arriver. Dans le cadre d'une appli web, ce n'est pas normal - comprendre erreur de conception, par exemple l'initialisation systématique de combo-box... - ; d'où la recommandation d'utiliser LIMIT.
De plus, il a identifié des jointures qui n'utilisent pas les index; catastrophiques en termes de perfs => produit cartésien : une tables de 100.000 lignes associées à une tables de 1000 lignes, va te générer un parcours de 100.000.000 lignes, exécuter les clauses Where lignes à lignes, stocker le résultat dans une table de travail et te renvoyer le résultat...
Bref, MySql passe son temps à créer des tables temporaires de travail sur disque, puis les efface puisque le résultat est trop gros pour être caché.
La prochaine requête arrive et rebelotte...
Je te suggère une intervention rapide paliative sur les paramètres indiqués, suivi plus tard d'une intervention curative et d'un réajustement de ces paramètres.
Etape 1 : modifier les variables indiquées /etc/mysql/my.cnf
Utilise le double des valeurs indiquées, sauf table_cache : 4096
Ajoutes les lignes
skip-bdb
log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
Vérifies que le parametre log est en commentaire ou inexistant :
#log = /var/log/mysql/mysql.log
et que les log binaires sont actifs :
log-bin = /var/log/mysql/mysql-bin.log
et relances Mysql
Laisser chauffer l'ensemble quelques heures...
Etape 2 : Mettre le bout des doigts dans le cambouis : ajuster tes requêtes SQL
1. Le plus simple est de créer les index qui manquent pour les jointures entre tables.
Commences par les requêtes lentes identifiées par Mysql dans le log /var/log/mysql/mysql-slow.log
Puis listes les autres requêtes SQL dans ton code qui utilisent plusieurs tables et les tables "moyennes" > 10.000 lignes
Connectes toi à Mysql via la console, 'mysql' ou installes l'outil web phpmyadmin plus convivial
Dans la suite, je parle de commande en mode console.
Pour chaque requete, execute un EXPLAIN "requeteSQL" ;
Notes les requetes et les tables associées dont la colonne "possible_keys" est à null avec la colonne "rows" > 500
Pour celles-ci, fait un explain sur les tables : Explain "tables";
La structure de la table s'affiche. Identifier les colonnes utilisées pour les jointures et créer les index manquants.
alter table add index (col_sans_index);
Pour l'aide en ligne : help alter table
2. Identifier les requetes qui font des select sans clause limit sur des tables de plus de 100 lignes. Controler que tu as besoin de l'ensemble de ces données. Si tu n'a besoin que des 10 1er résultats, ajouter "limit 10" à la requete.
Si tu as besoin de tout, tu as "probablement" un pb général de modèle de données. Et donc une grosse maintenance de structure, du code et de tes écrans seront à envisager.
Tu laisses chauffer le résultat quelques jours, tu relances mysqltuner et tu réajustes les paramètres my.cnf
NB:
Au travers de ces conseils, on reste sur une approche inversée de l'optimisation.
Tu travailles sur la partie la plus complexe et globalement la moins efficace.
Je m'explique :
- le pb est il pourquoi tes requetes sont lentes ?
- le pb est il pourquoi ton application les exécute aussi souvent ?
- le pb ne serait-il pas comment éviter que les internautes sollicitent aussi souvent ton application ?
Même si toutes ces étapes sont importantes, tu régleras 80% de ton pb sur le dernier point.
Je parle de ton application, pas de Mysqltuner. Laisses tes visiteurs faire le travail durant 2 jours. Relance le script, les conseils peuvent varier.
En dehors de MySQL, tu peux activer le profiling PHP avec le mod xdebug et optimiser les bouts de code les plus consommateurs.
