Je voudrais savoir quels sont les avantages [vraiment pratiques] qui peuvent être récoltés en exécutant la OPTIMIZE TABLE tbl_namerequête dans MySQL Server.

J'ai vérifié cela une fois et j'ai constaté qu'après cette exécution, le prochain hit DB prend beaucoup de temps peut être dû à la relocalisation de fragments, mais les hits suivants montrent une sorte de performance, je ne sais pas si la mise en cache des requêtes fait cette astuce avec l'optimisation ou l'optimisation seule fait cette astuce.

Quelqu'un peut-il me guider avec des valeurs de différence de performances réelles si possible afin que je puisse aller plus loin, car travailler avec MySQL gagne en gravité dans notre projet.

N'oubliez pas qu'OPTIMIZE TABLE n'effectue pas de défragmentation. En interne, OPTIMIZE TABLE effectue plusieurs opérations (copie de données dans un fichier temporaire, recréation d'index, recalcul des statistiques d'index). En fait, l'exemple que je possède peut être exécuté manuellement comme indiqué.

Exemple: si vous optimisez mydb.mytable, vous entrez cette commande:

OPTIMIZE TABLE mydb.mytable;

Notez que mysql effectue quelque chose de ce qui suit sous le capot:

CREATE TABLE mydb.mytable2 LIKE mydb.mytable;
ALTER TABLE mydb.mytable2 DISABLE KEYS;
INSERT INTO mydb.mytable2 SELECT * FROM mydb.mytable;
ALTER TABLE mydb.mytable2 ENABLE KEYS;
DROP TABLE mydb.mytable;
ALTER TABLE mydb.mytable2 RENAME mydb.mytable;
ANALYZE TABLE mydb.mytable;

Ceci est très utile pour les tableaux qui connaissent un volume élevé de mises à jour et de suppression

Cette opération peut accomplir deux choses

1. Empêchez mysql de parcourir les fragments d'une table pour tenter de charger des données dans les fragments de bonne taille. L'élimination de ces fragments réduira cette opération.

2. Le fait de recalculer les statistiques d'index aide MySQL Query Optimizer à construire de meilleurs plans EXPLAIN. Sinon, les requêtes peuvent se détériorer dans le temps d'exécution car l'optimiseur de requêtes MySQL a décidé de faire de mauvaises suppositions sur le plan EXPLAIN. Ce serait un symptôme certain d'une table qui a eu un volume élevé de mises à jour et de suppression.

CAVEAT

En ce qui concerne la mise en cache, la mise en cache prend une plongée rapidement en raison d'une analyse complète de la table. Pour les pages d'index MyISAM, elles entrent et sortent du cache de clés MyISAM. Pour InnoDB, les pages de données et d'index entrent et sortent du pool de tampons InnoDB.