SQL DELETE производительность

Question

delete from a A where a.ID = 132.

Таблица A содержит около 5000 записей, и A.ID является первичным ключом в таблице A. Но удаление занимает много времени. Иногда это становится тайм-аутом. Эта таблица содержит три индекса, и на нее ссылаются три внешних ключа. Может кто-нибудь объяснить мне, почему это занимает много времени, хотя мы удаляем на основе первичного ключа. И, пожалуйста, скажите мне, как оптимизировать эту проблему ...?

Answer 1

Возможные причины:

1) каскадные операции удаления

2) триггер (ы)

3) тип столбца первичного ключа отличается от целого числа, поэтому для сравнения необходимо принудительно преобразовать тип каждого значения pk. это требует полного сканирования таблицы.

4) действительно ли ваш запрос заканчивается точкой, как вы разместили его в вопросе? если это так, число может рассматриваться как число с плавающей запятой вместо целого числа, вызывая преобразование типа, подобное 3)

5) ваш запрос на удаление ожидает другого медленного запроса для снятия блокировки

Answer 2

Очевидно, это не должно занять много времени. Однако здесь недостаточно информации, чтобы понять, почему именно. Я могу сказать вам, однако, что вы должны сосредоточиться на иностранных ключах.

Это может замедлить работу, если налагает ограничения на другие, гораздо большие таблицы. Вы также можете узнать, что ваши тайм-ауты происходят из-за проверок целостности, которые предотвращают удаление (тогда возникает вопрос, почему вы не получаете исключения вместо тайм-аута).

Следующим моим шагом будет удаление внешних ключей, а затем проверка производительности. Затем добавляйте каждый из них по очереди и проверяйте производительность по ходу работы.

Другие операции (например, вставки, выборки, обновления) занимают много времени?

Answer 3

Попробуйте обновить статистику. 5000 строк не имеет большого значения. Если вы делаете это регулярно, вы также должны запланировать обслуживание этой таблицы (то есть пересоздать индексы, обновить статистику и т. Д.)

Answer 4

Первая мысль: индексы на внешних ключах?

• Это связано с каскадным удалением, упомянутым
• Проверяются все отключения дочерних таблиц, и если у вас есть 500 000 дочерних строк, это может занять некоторое время, конечно ...

Вторая мысль: триггеры стреляют?

• В этой таблице или в дочерних таблицах или при попытке каскадирования с помощью кода и т. Д.
• Не дай Бог, курсор для каждой строки в DELETED ...

Answer 5

Как уже отмечалось, вероятными подозреваемыми являются внешние ключи.

Во-первых, потому что ON DELETE CASCADE может набирать обороты, если на зависимые таблицы в свою очередь ссылаются другие таблицы, на которые в свою очередь могут ссылаться, и так далее.

Во-вторых, потому что другие пользователи могут иметь блокировки на строках, которые необходимо удалить. Это наиболее вероятная причина тайм-аутов. То, как это работает, будет зависеть от вкуса и версии вашей базы данных. Например, более старые версии Oracle (<= 8.0) должны были блокировать всю зависимую таблицу, если столбцы внешнего ключа не были проиндексированы. </p>