Liste des tableaux pour tronquer en toute sécurité à Magento?

Avant de faire quoi que ce soit

• assurez-vous d'abord de tester l'élimination de ces données dans un environnement non productif.
• Toujours faire des sauvegardes avant de perdre les données pour toujours.
• assurez-vous que vous êtes truncateing, pas drop ing.
• probablement une bonne idée de tout réindexer via shell après suppression de masse des enregistrements

---

mise à Jour:

Vous pouvez utiliser n98-magerun module pour nettoyer vos tables.

Ou le faire manuellement en suivant les instructions ci-dessous.

---

pour développer la réponse de Jim, Magento Support n'a pas besoin du contenu de ces tables quand ils demandent une copie de votre base de données, de sorte que vous pouvez les considérer comme non essentiels.

tables de Cache

core_cache
core_cache_tag

les données de Cache sont temporaires. Les nettoyer devrait être sans danger.

tables de Session

core_session

Pas besoin de garder ans session. De nouvelles sessions seront automatiquement créées (bien que cela provoquera une déconnexion/rupture de flux de caisse).

tableaux des débits de données

dataflow_batch_export
dataflow_batch_import

Il y a essentiellement des journaux à chaque fois qu'un lot est exécuté et non critique.

logs Admin

enterprise_logging_event
enterprise_logging_event_changes

ce sont des logs des admins qui font quoi dans le backend. Très bien pour traquer "qui a cassé quoi" mais n'a pas besoin d'être gardé pour toujours. Vous pouvez tronquer ils.

Pro-tip: assurez-vous que vous nettoyez les vieux dossiers en Système > Configuration > Avancé > Système > Admin Actions Du Journal D'Archivage

tables de Support

enterprise_support_backup
enterprise_support_backup_item

historique du support de Magento, peut ou peut ne pas exister pour vous.

Index des tableaux

index_event
index_process_event

un journal des entrées de l'index qui doivent être mises à jour. Cependant, ils ne se suppriment pas eux-mêmes une fois qu'ils sont obsolète.

des tableaux de bord

log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online

Journal de données, utilisé. Cependant, j'ai vu que les modules "Trier par la plupart des vues" utilisent le log_visitor_info table alors soyez prudents.

Pro-tip: assurez-vous que vous nettoyez les vieux dossiers en Système > Configuration > Avancé > Système > Journal De Nettoyage (cela ne concerne que les visiteurs, les clients et les urls)

tableaux

report_event
report_viewed_product_index

il s'agit de tableaux agrégés qui peuvent être reconstruit lors de l'exécution de rapports.

---

les autres tables qui peuvent utiliser une taille de temps en temps sont

tableaux des citations

sales_flat_quote
sales_flat_quote_address
sales_flat_quote_address_item
sales_flat_quote_item
sales_flat_quote_item_option
sales_flat_quote_payment
sales_flat_quote_shipping_rate

si le fait d'avoir abandonné les données du cart à 3 ans n'est pas important pour vous, envisagez de les tronquer. Gardez à l'esprit que les chariots actuels sont ici, alors programmez ceci pendant les heures creuses ou supprimez les rangées avec updated_at plus de X jours.

Pro-tip: installer Aoe_QuoteCleaner

tables de stadification

si vous utilisez la fonction de mise en scène D'Enterprise, vous pourriez commencer à voir des tables avec le s_ préfixe. Il n'y a pas de nettoyage pour ceux-ci une fois que le site de transit est enlevé. Si votre enterprise_staging la table est vide, vous n'avez plus besoin de ces tables.

tables Changelog

catalog_category_flat_cl
catalog_category_product_cat_cl
catalog_category_product_index_cl
catalog_product_flat_cl
catalog_product_index_price_cl
cataloginventory_stock_status_cl
catalogsearch_fulltext_cl
enterprise_url_rewrite_category_cl
enterprise_url_rewrite_product_cl
enterprise_url_rewrite_redirect_cl

Magento introduit des déclencheurs MySQL qui écrivent pour modifier les tables de log lorsque les données de certaines tables sont modifier. Plus tard, l'indexeur scheduler récupère les entrées du journal des modifications et met à jour les éléments. Cependant, il ne nettoie pas quand il est fait. Vous pouvez effacer ces de temps en temps.

catégorie et produit tableaux plats

catalog_category_flat_store_1
catalog_category_flat_store_2
catalog_category_flat_store_3
catalog_category_flat_store_4
catalog_category_flat_store_5
catalog_category_flat_store_6
catalog_category_flat_store_7
catalog_product_flat_1
catalog_product_flat_2
catalog_product_flat_3
catalog_product_flat_4
catalog_product_flat_5
catalog_product_flat_6
catalog_product_flat_7

Ces tables, j'ai tendance à drop. Après un reindex, ils se recréeront. Dans certains cas, stocker 7 n'existe peut-être plus mais vous avez toujours la table plate morte.

réécriture D'URL tables

faites attention ici, vous ne voudrez peut-être pas les tronquer tous.

core_url_rewrite
enterprise_url_rewrite

Vérifiez D'abord les enregistrements qui sont is_system = 0. Si vous ne voulez pas tronquer, vous perdrez les redirections personnalisées. Essayez DELETE FROM core_url_rewrite WHERE is_system = 1 à la place. Réindexer les réécritures va re-remplir cette table avec le reste.

plus de tableaux de rapport

report_viewed_product_aggregated_daily
report_viewed_product_aggregated_monthly
report_viewed_product_aggregated_yearly

ceux-ci sont agrégés et peuvent être reconstruits (comme les index).