Почему ограничение CASCADE предотвращает любые операции с таблицами, имеющими массовые записи?

Question

Поскольку я задал вопрос здесь на Пожалуйста, порекомендуйте лучший вариант массового удаления , ограничение CASCADE - это то, что не позволяет мне удалять записи во всех таблицах, когда они были загружены массовыми записями.

Есть ли какая-то причина, по которой CASCADE требует времени, когда DELETE FROM table1;Или TRUNCATE table1 CASCADE предпринимается?

К вашему сведению, я использую PostgreSQL 8.1.4.Хотя я устарел, когда я удаляю ограничение CASCADE в своих таблицах (перечисленных в верхней ссылке), запросы DELETE и TRUNCATE работают нормально.

Однако мне нужен CASCADE!Я не могу просто снять ограничение.Пожалуйста, помогите мне в этом.

Answer 1

Распространенной ошибкой является отсутствие индекса в столбце внешнего ключа.При удалении одной строки из ссылочной таблицы должны быть найдены все ссылающиеся строки.Без индекса каждая строка приведет к медленному последовательному сканированию.С индексом - легко и быстро.

Возможно, это ваша проблема.

Answer 2

ON CASCADE DELETE для небольших операций, но плохо работает для больших.Чтобы понять, почему мы должны смотреть на то, что происходит за кулисами: на PostgreSQL мы используем триггеры.

Так что, если мы удаляем из родительской таблицы, для каждой удаляемой строки она идет и удаляется на дочернемстол тоже.Это происходит для каждой удаленной строки.Теперь обратите внимание, что последовательные сканирования в PostgreSQL относительно дешевы, поэтому вы можете форсировать большое количество сканирований индекса, когда одно последовательное сканирование будет намного быстрее.

Итак, предположим, что в таблице 1 мы удаляем 1000 записейи это означает, что в таблице 2 мы удаляем 10000 записей.Если мы делаем это правильно, мы идем и удаляем из таблицы 2, выполняя один просмотр , чтобы сделать это.Может потребоваться несколько секунд на хорошем оборудовании.Затем мы идем и удаляем из родительской записи, и это быстро.Хорошо, верно?

Теперь предположим, что мы используем триггеры для удаления .....

Сканирование по таблице 1, для каждой из 1000 строк, которые мы удаляем, сканирование по индексу таблицы 2,удалить 10 строк, перейти к следующему.Мы полностью теряем любую помощь, которую можем получить от процедур предварительной выборки ОС, и заменяем много избыточных, случайных чтений страниц гораздо меньшим числом последовательных чтений.Сейчас мы тратим много времени на ожидание поворота дисковых дисков и движения головок.Ой ......

Триггеры ON DELETE CASCADE имеют свое место.Они отлично работают, если мы просто удаляем несколько записей.Но они очень быстро распадаются на массовые удаления.Оберните все свои удаления в транзакции и сначала удалите из дочерних таблиц, и это будет намного быстрее.

Answer 3

Использование каскадного удаления - очень плохая идея! Теперь вы узнали, почему. Если большое количество записей будет удалено, это займет слишком много времени. Вы должны правильно удалить, начиная сначала с дочерних записей. Если вы удаляете большое количество записей, вам может потребоваться написать сценарий для удаления в пакетном режиме, чтобы избежать блокировки и слишком долгого выполнения одной команды.

Позвольте мне объяснить, почему это становится медленнее. Предположим, вы хотите удалить 1000 записей из родительской таблицы, которая называется TableA. Здесь задействованы три дочерних таблицы. ТаблицаB в среднем 10 записей на родительскую запись. TableC в среднем 5 записей на родительскую запись. TableD в среднем 100 записей на одну запись parant. Таким образом, удаление 1000 записей в Таблице А на самом деле включает удаление 115000 записей. Теперь предположим, что вы удаляете 10000 записей из таблицы А, теперь ваше каскадное удаление приведет к удалению 1 150 000 записей. Сейчас в большинстве баз данных родительская таблица может иметь значительно больше трех связанных таблиц (у нас есть одна с более чем 100 FKS). Если бы мы разрешили каскадное удаление в наших базах данных, и кто-то попытался удалить 1000 записей, они бы в итоге удалили сотни миллионов записей.