Ce sujet est résolu. Voici une description du problème et de la solution.
Problème : Les tables WPML yng_icl_translation_status et yng_icl_translate sont devenues très volumineuses, occupant une part significative de la base de données. Malgré l'utilisation du plugin wpml_delete_jobs, la taille des tables n'a pas été réduite efficacement. Solution : Si vous rencontrez ce problème, nous vous recommandons de suivre ces étapes pour optimiser et réduire la taille de vos tables WPML : 1. Exécutez le processus de réduction de la taille des tables WPML en suivant ce guide : https://wpml.org/errata/reducing-size-of-icl_translate_job-icl_translate-and-other-wpml-tables/ 2. Avant de lancer le processus, faites des captures d'écran des tailles des tables de base de données avant et après pour comparer. 3. Vérifiez si le processus se termine avec succès ou si des erreurs apparaissent dans la console du navigateur ou ailleurs dans le backend. 4. Si le problème persiste, essayez les commandes suivantes :
OPTIMIZE TABLE nom_de_votre_table;
Cette commande défragmente la table, récupère l'espace inutilisé et réorganise les données. Pour les tables InnoDB, cela peut prendre plus de temps.
ALTER TABLE nom_de_votre_table ENGINE=InnoDB;
Cette commande reconstruit la table et les index, aidant à récupérer l'espace utilisé par les index fragmentés. 5. Ajustez les paramètres InnoDB dans MySQL pour purger plus fréquemment les logs de transactions, en modifiant par exemple la variable
innodb_purge_interval
.
Si ces solutions ne résolvent pas votre problème ou si elles semblent obsolètes ou inapplicables à votre cas, nous vous recommandons vivement de consulter les problèmes connus sur https://wpml.org/known-issues/, de vérifier la version du correctif permanent et de confirmer que vous avez installé les dernières versions des thèmes et plugins. Si nécessaire, n'hésitez pas à ouvrir un nouveau ticket de support sur le forum de support WPML.
Il s'agit du forum d'assistance technique de WPML, le plug-in multilingue pour WordPress.
Il est accessible à tous, toutefois seuls les clients de WPML peuvent y publier leurs messages. L'équipe du WPML répond sur le forum 6 jours par semaine, 22 heures par jour.
Aucun de nos assistants n'est disponible aujourd'hui sur le forum French. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.
Contexte de la question:
I am trying to optimize and reduce the size of the WPML tables in my database for my site lien caché. The tables yng_icl_translation_status (511.58 MB) and yng_icl_translate (263.69 MB) have become very large, taking up almost half of the entire database size. I have already tried using the wpml_delete_jobs plugin to reduce the table sizes but haven't been successful.
Symptômes:
The WPML tables yng_icl_translation_status and yng_icl_translate are very large and taking up significant space in the database.
Questions:
How can I optimize and reduce the size of the WPML tables yng_icl_translation_status and yng_icl_translate?
I actually ran this process yesterday, and the database table sizes shown in the screenshot I previously sent reflect the latest values after I completed the optimization. In the new screenshot I’m attaching, you can see that after running the process yesterday, the size of the yng_icl_translation_status table has increased, while the size of the yng_icl_translate table has decreased (it was 341.73 MB before).
I also just ran the process again as per your suggestion, but this time it reports that no tables can be deleted. I’m attaching a screenshot of this message as well for your reference.
Please let me know if there are any further steps I can take or if you have additional suggestions.
Les langues: Anglais (English )Allemand (Deutsch )Français (Français )
Fuseau horaire: Europe/Zagreb (GMT+01:00)
We checked this and some of the possible causes of this may be this:
1. **Fragmentation**: When rows are deleted, gaps are left in the table’s storage. InnoDB doesn’t automatically shrink tables after deletions, so space remains allocated until explicitly released.
2. **Index Fragmentation**: Indexes, particularly large or complex ones, can become fragmented after rows are deleted, making them inefficient and consuming more space.
3. **Transaction Logs**: InnoDB keeps transaction logs (undo/redo) to ensure data integrity. Deleting many rows can generate significant log data, which may temporarily increase the space used by the table until the logs are purged.
4. **Table Overhead**: MySQL tables have overhead (internal structures and caches) that can grow, even when data is deleted. This is a result of how MySQL manages data and reserves space for future operations.
That being said, can you try this?
1. Run `OPTIMIZE TABLE your_table_name;`. This command defragments the table, reclaims unused space, and reorders the data. It works for both InnoDB and MyISAM tables, though it may take longer for large tables in InnoDB. This step will also update table statistics for better performance.
2. If index fragmentation is the issue, you can rebuild the indexes using the following command:
ALTER TABLE your_table_name ENGINE=InnoDB;
This will rebuild the table and indexes, helping reclaim space used by fragmented indexes.
3. If transaction logs (undo/redo logs) are contributing to the table size, you may need to adjust the frequency at which logs are purged. You can configure the InnoDB settings in MySQL, for example by modifying the `innodb_purge_interval` variable to purge logs more frequently.
Can you try any of the above and let us know if it helped? Have a backup offcourse.
Thank you very much for the detailed and clear information. The database side is a bit beyond my expertise, so I’ll be working with a friend to implement your suggestions. However, this might take some time. I will follow your guidance to try and resolve the issue.
If you have any further recommendations, I would be happy to hear them. Thanks again for your support.
Les langues: Anglais (English )Allemand (Deutsch )Français (Français )
Fuseau horaire: Europe/Zagreb (GMT+01:00)
Sure, take your time. We also suspect it may be the InnoDB logs that have caused the increase and you may need to wait for whenever the scheduled cleanup of the logs occurs, per the DB settings (or see to do this manually, if possible).
