Magento で安全に切り捨てることができるテーブルのリストはありますか? 安全とは、製品を保存することを意味します。
いくつかありますが、他にもある場合は知りたいです。
truncateingではなく、 ingしていることを確認してくださいdrop。このn98-magerunモジュールを使用して、テーブルをクリーンアップできます。
または、以下の手順に従って手動で行います。
Jim の回答をさらに詳しく説明すると、Magento サポートは、DB のコピーを要求するときにこれらのテーブルの内容を必要としないため、それらは必須ではないと考えることができます。
core_cache
core_cache_tag
キャッシュ データは一時的なものです。これらをクリアしても安全です。
core_session
1 年前のセッションを維持する必要はありません。新しいセッションが自動的に作成されます (ただし、ユーザーがログアウトされたり、現在のチェックアウト フローが中断されたりします)。
dataflow_batch_export
dataflow_batch_import
基本的に、バッチが実行されるたびにログがあり、重要ではありません。
enterprise_logging_event
enterprise_logging_event_changes
これらは、バックエンドでどの管理者が何をしているかのログです。「誰が何を壊したか」を追跡するには非常に便利ですが、永久に保持する必要はありません。これらは安全に切り捨てることができます。
プロのヒント: [システム] > [構成] > [詳細設定] > [システム] > [管理者アクション ログのアーカイブ]で古いレコードを消去していることを確認してください。
enterprise_support_backup
enterprise_support_backup_item
Magento からのサポート履歴は、存在する場合と存在しない場合があります。
index_event
index_process_event
更新が必要なインデックス エントリのバック ログ。ただし、廃止されても自分自身を削除することはありません。
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
ほとんど未使用のログデータ。ただし、「Sort by Most Viewed」モジュールでlog_visitor_infoテーブルが使用されているのを見たことがあるので注意してください。
プロのヒント: [システム] > [構成] > [詳細設定] > [システム] > [ログのクリーニング]で古いレコードを消去していることを確認してください(これは、訪問者、顧客、および URL のみを行います)
report_event
report_viewed_product_index
これらは、レポートの実行時に再構築できる集計テーブルです。
たまにプルーニングを使用できる他のテーブルは次のとおりです。
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
3 年前の放棄されたカート データが重要でない場合は、これらを切り捨てることを検討してください。現在のカートがここにあることに注意してください。営業時間外にスケジュールするかupdated_at、X 日より古い行を削除してください。
プロのヒント: Aoe_QuoteCleanerをインストールします
s_Enterprise のステージング機能を使用している場合、接頭辞が付いたテーブルが表示されることがあります。ステージング サイトが削除されると、これらのクリーンアップはありません。テーブルが空の場合、enterprise_stagingこれらのテーブルはもう必要ありません。
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 は、特定のテーブルのデータが変更されたときに変更ログ テーブルに書き込む MySQL トリガーを導入しました。その後、スケジューラ インデクサーが変更ログ エントリを取得し、項目を更新します。ただし、完了してもクリーンアップされません。これらを時々クリアすることができます。
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
これらのテーブルは私がする傾向がありdropます。再インデックスの後、それらは自分自身を再作成します。場合によっては、ストア7がもう存在しない可能性がありますが、まだフラットなテーブルが残っています。
ここで注意してください。これらすべてを切り捨てたくない場合があります。
core_url_rewrite
enterprise_url_rewrite
であるレコードを最初に確認しますis_system = 0。その場合、切り捨てたくない場合は、カスタム リダイレクトが失われます。DELETE FROM core_url_rewrite WHERE is_system = 1代わりに試してください。再インデックスの書き換えにより、このテーブルに残りのデータが再入力されます。
report_viewed_product_aggregated_daily
report_viewed_product_aggregated_monthly
report_viewed_product_aggregated_yearly
これらは集約され、再構築できます (インデックスと同様)。
Magentoサポートの問題をログに記録し、データベースダンプを提供するように求められた場合、提供されるスクリプトは、次のテーブルのスキーマのみをダンプします。
core_cache
core_cache_option
core_cache_tag
core_session
dataflow_batch_export
dataflow_batch_import
enterprise_logging_event
enterprise_logging_event_changes
enterprise_support_backup
enterprise_support_backup_item
index_event
index_process_event
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
report_event
report_viewed_product_index
Magentoのサポートが問題を解決するためにこれらのテーブルの内容を必要としない場合、それらを安全に切り捨てることができるというのは安全な仮定です。
catalog_product_flat_*テーブルとテーブルはcatalog_category_flat_*、インデックスの再作成によって再入力されるため、切り捨てることもできます。
ユーザーはcore_url_rewriteバックエンドから手動でテーブルにエントリを追加できますが、同じURLキーを持つ2つの製品prカテゴリが、切り捨てた後も常に同じURLになることを保証したくありませんcore_url_rewrite。安全に切り捨てることができると私が頼りにしているものではありません。
「catalogrule_product」と「catalogrule_product_price」を切り捨てることもできるリストに追加したいと思います。[Pormos] > [カタログ ルール] で [ルールの適用] を実行して再生成できます。このテーブルが安全であることを確認するために、このテーブルを何度も切り捨てました。注意！ルールを再実行するまで、カタログ ルールの価格はすべてフロントエンドから消えます。
また、これらのテーブルがクリアされた場合にサイトで何が起こるかを誰かが説明できるかどうかも知りたい. たとえば、core_session を削除すると (データベースを使用して保存している場合)、現在「ログインしている」すべての顧客セッションが削除されると思いますが、ゲストのカートも削除されますか?
ieadmin_*テーブルを切り捨てることが有用であるとは思えません。上記の唯一の価値のあるテーブルのリストに従うと、これが行われます。管理者を再度追加する必要があります。
それ以上のテーブルをチェックしませんでした。私のインストールの最初の3つのテーブルに偶然出くわしました。