Dois-je réindexer la table mysql après une suppression en masse?

J'ai une table dans MySQL avec beaucoup de INSERT et SELECT à chaque seconde. Et il y a une suppression en masse de certaines données plus anciennes une fois par jour. Dois-je réindexer la table après la suppression? Je veux augmenter les performances. Quelqu'un peut-il suggérer quelques conseils? Utilisation de «innodb» comme moteur de stockage. Dois-je le changer? Je pense que c'est mieux pour l'insertion et la sélection simultanées. Veuillez donner vos suggestions. Dois-je faire une réindexation?

Merci d'avance..

Devez-vous optimiser les tables lorsque vous utilisez InnoDB? Oui et non, selon votre charge de travail et si vous rencontrez ou non des problèmes de performances.

Un copier-coller sans vergogne de la documentation MySQL :

Pour les tables InnoDB, OPTIMIZE TABLE est mappé sur ALTER TABLE, qui reconstruit la table pour mettre à jour les statistiques d'index et libérer de l'espace inutilisé dans l'index cluster. Ceci est affiché dans la sortie de OPTIMIZE TABLE lorsque vous l'exécutez sur une table InnoDB, comme illustré ici:

mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table    | Op       | Msg_type | Msg_text                                                          |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status   | OK                                                                |
+----------+----------+----------+-------------------------------------------------------------------+

Cette opération n'utilise pas la création d'index rapide. Les index secondaires ne sont pas créés aussi efficacement car les clés sont insérées dans l'ordre dans lequel elles apparaissent dans la clé primaire. Voir Section 14.14.6, «Limitations de la création d'index rapide».

InnoDB stocke les données à l'aide d'une méthode d'allocation de pages et ne souffre pas de la fragmentation de la même manière que les moteurs de stockage hérités (tels que MyISAM). Lorsque vous envisagez d'exécuter ou non l'optimisation, tenez compte de la charge de travail des transactions que votre serveur traitera:

• Un certain niveau de fragmentation est attendu. InnoDB ne remplit que les pages à 93%, pour laisser de la place aux mises à jour sans devoir fractionner les pages.

• Les opérations de suppression peuvent laisser des lacunes qui laissent les pages moins remplies que souhaité, ce qui pourrait rendre utile l'optimisation du tableau.

• Les mises à jour des lignes réécrivent généralement les données sur la même page, selon le type de données et le format de ligne, lorsqu'un espace suffisant est disponible. Voir Section 14.10.5, «Fonctionnement de la compression pour les tables InnoDB» et Section 14.12.1, «Présentation du stockage des lignes InnoDB».

• Les charges de travail à concurrence élevée peuvent laisser des lacunes dans les index au fil du temps, car InnoDB conserve plusieurs versions des mêmes données grâce à son mécanisme MVCC. Voir Section 14.5.12, «Multi-versions d'InnoDB».

Vous pouvez réindexer la table et même la réduire. Cependant, si vous souhaitez retarder une telle maintenance sur disque, vous devez au moins recalculer les statistiques d'index.

Sans recalculer les statistiques d'index, l'optimiseur de requêtes MySQL peut faire de mauvais choix pour les plans EXPLAIN de requête. Cela pourrait nuire aux SELECT si les statistiques des données inexistantes sont toujours présentes. Cela est vrai pour MyISAM et InnoDB.

Vous n'avez pas besoin de réduire la table pour calculer les statistiques d'index, bien que ce soit mieux pour les performances globales.

Pour calculer les statistiques de tous les index d'une table, vous devez exécuter

ANALYZE TABLE tablename;

Tu pourrais faire ça tous les soirs. Il ne tentera pas de défragmenter ou de réduire les données. Vous pourriez probablement le faire une fois par semaine en courant OPTIMIZE TABLE tablename;. Cela fera également le ANALYZE TABLE tablename;pour vous après la réduction du fichier physique de la table ( .ibdpour InnoDB ou .MYIpour MyISAM) ou.

OPTIMIZE TABLE n'est presque jamais nécessaire sur InnoDB.

Supprimez-vous des enregistrements en fonction de l'âge? Si c'est le cas, vous pouvez rendre la "suppression en bloc" essentiellement gratuite en utilisant PARTITIONing et DROP PARTITION. Plus de détails ici: http://mysql.rjweb.org/doc.php/partitionmaint