У нас есть сайт, который за несколько лет создал 10 миллионов записей в таблице paraps_item. Это результат большого количества переносов данных (где задействованы абзацы), и теперь есть много сирот (вероятно, 90% из них).
Entity Reference Revisions теперь поставляется с командой Drush для «очистки» потерянных сущностей. Кажется, это работает, но с таким количеством просмотров кажется, что просмотр всех из них займет очень много времени. Следует отметить, что они нет осиротел в результате удаления хост-объекта. Из-за того, как данные переносятся, абзацы перестраиваются и заменяются в соответствии с определением миграции. Мы не можем изменить это сейчас, пока в подмножестве данных не появится какой-то хэш, указывающий, следует ли нам импортировать или пропустить.
У меня есть подозрение, что это приводит к тому, что запрос в формах редактирования при редактировании абзаца со временем становится медленнее, что теперь приводит к невозможности его выполнения (MariaDB перестает отвечать). Несмотря на то, что все поля индексируются по схеме Paragraphs, эффективность снижается.
Если я очистил и позволил ему удалить, например, 200 000 элементов, запуск OPTIMIZE sql для таблицы paraps_item, кажется, поддерживает эту теорию. Первое редактирование занимает 8 секунд, чтобы загрузить абзац, после этого это происходит почти мгновенно. Итак, удаление всех неиспользуемых абзацев — это то, что я думаю, мы должны сделать. Я понимаю, что OPTIMIZE в InnoDB приводит к перестроению индекса, но в случаях, когда вы обновляете версии базы данных, эти данные настолько велики, что я думаю, что они не могут перестраиваться при определенном пороге.
Есть ли более быстрый способ запрашивать и удалять потерянные абзацы помимо очистки?
