Список таблиц для безопасного усечения в Magento?

Ответ 1

Прежде чем что-либо сделать

• Убедитесь, что вы сначала протестировали очистку этих данных в непроизводственной среде.
• Всегда делайте резервные копии, прежде чем потерять данные навсегда.
• Убедитесь, что вы truncate ing, а не drop ing.
• Вероятно, хорошая идея перевернуть все через оболочку после массового удаления записей

Обновление:

Вы можете использовать этот n98-magerun модуль для очистки ваших таблиц.

Или сделайте это вручную, следуя инструкциям ниже.

Чтобы расширить ответ на Jim, Magento Support не нуждается в содержимом этих таблиц, когда они запрашивают копию вашей БД, поэтому вы можете считать их несущественными.

Таблицы кэша

core_cache
core_cache_tag

Данные кэша являются временными. Очистка должна быть безопасной.

Таблицы сеансов

core_session

Не нужно проводить летние сессии. Новые сеансы будут автоматически созданы (хотя это приведет к тому, что люди будут выходить из системы/прерывать текущий поток проверки).

Таблицы потоков данных

dataflow_batch_export
dataflow_batch_import

В каждый момент времени, когда пакет запускается и не критичен, по существу записаны журналы.

Журналы администратора

enterprise_logging_event
enterprise_logging_event_changes

Это журналы, администраторы которых делают что-то в бэкэнде. Очень приятно отслеживать "кто сломал что", но не нужно вечно хранить. Вы можете безопасно обрезать их.

Pro-tip: убедитесь, что вы очищаете старые записи в System > Configuration > Advanced > System > Архивирование журнала действий администратора

Таблицы поддержки

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, поэтому будьте осторожны.

Pro-tip: убедитесь, что вы очищаете старые записи в 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-летние данные о брошенных тележках, подумайте об их усечении. Имейте в виду, что текущие тележки здесь, поэтому планируйте это в нерабочее время или удалите строки с updated_at старше X дней.

Pro-tip: установите 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

Они агрегируются и могут быть перестроены (например, индексы).

Ответ 2

Когда вы регистрируете проблему с поддержкой Magento, и они просят предоставить дамп базы данных, script они дают вам дампы для схемы только для следующих таблиц:

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_* также могут быть усечены, так как reindex будет их повторно заполнять.

Пользователь может добавлять записи в таблицу core_url_rewrite вручную с обратной стороны, и я не хотел бы гарантировать, что две категории продуктов pr с одинаковыми URL-ключами всегда будут иметь одинаковые URL-адреса после усечения core_url_rewrite. Это не я, я полагался бы на возможность усечения благополучно.

Ответ 3

Я хочу добавить в список, что вы также можете усечь "catalogrule_product" и "catalogrule_product_price". Вы можете восстановить его, выполнив Применить правила в Pormos > Правила каталога. Я несколько раз обрезал этот стол, чтобы понять, что это безопасно. NB! Все цены вашего каталога будут исчезать из интерфейса, пока вы не заново запустите правила.

Мне также хотелось бы узнать, может ли кто-нибудь описать, что происходит с сайтом, если эти таблицы очищены. Например. Я предполагаю, что отбрасывание core_session (если мы используем базу данных для их хранения) приведет к потере всех текущих сеансов пользователя, зарегистрированных в журнале, будет ли это также опускаться по телегам гостей?

Ответ 4

Я сомневаюсь, что полезно усечь таблицы i.e. admin_ *. Это делается, если вы следуете приведенному выше списку единственных достойных таблиц. Вам придется добавить администратора снова.

Не проверять дальнейшую таблицу. Просто наткнулся на первые 3 таблицы моей установки.