Magentoで安全に切り捨てられるテーブルのリスト？
Magentoで安全に切り捨てられるテーブルのリストはありますか？安全とは、製品を保存することです。
私はいくつか持っていますが、もっとあるかどうか知りたいです：
core_url_rewrite # Only safe if no custom rewrites are in place
catalog_product_flat_1
catalog_product_flat_# (# depends on the multistore)
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
この質問は現在8年近くになっていることに注意してください。テーブルをランダムに切り捨てるのではなく、何かを行う前にバックアップすることをお勧めします。
何かする前に
- 最初に非実稼働環境でこのデータのクリアをテストしてください。
- データを永久に失う前に、常にバックアップを作成してください。
truncateingではなく、dropingであることを確認してください。- レコードを大量に削除した後、シェルを介してすべてのインデックスを再作成することをお勧めします
更新：
this n98-magerun module を使用して、テーブルをクリーンアップできます。
または、以下の手順に従って手動で実行してください。
Jimの答えを拡張するために、Magentoサポートは、DBのコピーを要求するときにこれらのテーブルのコンテンツを必要としないため、これらは必須ではないと見なすことができます。
キャッシュテーブル
core_cache
core_cache_tag
キャッシュデータは一時的なものです。これらをクリアしても安全です。
セッションテーブル
core_session
1年前のセッションを維持する必要はありません。新しいセッションが自動的に作成されます（ただし、ユーザーがログアウトされたり、現在のチェックアウトフローが中断されたりします）。
データフローテーブル
dataflow_batch_export
dataflow_batch_import
基本的に、バッチが実行されるたびのログがあり、重要ではありません。
管理ログ
enterprise_logging_event
enterprise_logging_event_changes
これらは、管理者がバックエンドで何をしているかのログです。 「誰が何を壊したか」を追跡するのに非常に良いが、永久に保管する必要はない。これらを安全に切り捨てることができます。
ヒント：System> Configuration> Advanced> System> Admin Actions Log Archiving
サポート表
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
ほとんど使用されないログデータ。ただし、「ほとんどの視聴者による並べ替え」モジュールはlog_visitor_infoテーブルを使用するので注意が必要です。
ヒント：System> Configuration> Advanced> System> Log Cleaning（これは訪問者のみ、顧客、および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年経過したカートの放棄データが重要でない場合は、これらを切り捨てることを検討してください。現在のカートはここにあるため、営業時間外にスケジュールするか、X日より古いupdated_atの行を削除してください。
Pro-tip：install Aoe_QuoteCleaner
ステージングテーブル
エンタープライズのステージング機能を使用する場合、s_プレフィックスが付いたテーブルが表示される可能性があります。ステージングサイトが削除されると、これらのクリーンアップはありません。 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はもう存在しないかもしれませんが、それでもデッドフラットテーブルが残っています。
URL書き換えテーブル
ここで注意してください、これらすべてを切り捨てたくないかもしれません。
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テーブルにエントリを手動で追加できますが、core_url_rewriteを切り捨てた後、同一のURLキーを持つ2つの製品またはカテゴリのURLが常に同じになることを保証したくありません。安全に切り捨てられることを期待しているものではありません。
リストに追加して、「catalogrule_product」と「catalogrule_product_price」も切り捨てることができます。 Pormos>カタログルールでルールの適用を実行することにより、再生成できます。安全であることを知るために、このテーブルを何度も切り捨てました。 NB！すべてのカタログルール価格は、ルールを再実行するまでフロントエンドから消えます。
また、これらのテーブルがクリアされた場合にサイトで何が起こるかを誰かが説明できるかどうかを確認したいと思います。例えば。 core_sessionを削除すると（データベースを使用してそれらを保存している場合）、現在のすべての顧客の「ログイン」セッションが削除され、ゲストのカートも削除されますか？
つまり、admin_ *テーブルを切り捨てることが役立つとは思えません。価値のある唯一の表の上記のリストに従う場合、これは行われます。管理者を再度追加する必要があります。
それ以上のテーブルをチェックしませんでした。インストールの最初の3つのテーブルにつまずいただけです。