SQL Server - Плохая производительность PK delete

У меня есть таблица в SQL Server 2008 R2, состоящая из примерно 400 строк (почти ничего) - у нее есть кластерный индекс первичного ключа (который является идентификатором). Таблица ссылается посредством ссылочной целостности (без каскадного удаления или обновления) примерно на 13 других таблиц.SQL Server - Плохая производительность PK delete

Вкладыши/Обновления/Получения почти мгновенные - мы говорим о раздельной секунде (как и следовало ожидать). Тем не менее, удалить с помощью ПК требуется до тех пор, как 3 минуты, и я никогда не видел его быстрее, чем 1,5 минуты:

DELETE FROM [TABLE] WHERE [TABLE].[PK_WITH_CLUSTERED_INDEX] = 1

Индекс был сильно фрагментирован - 90%. Я перестроил и реорганизовал этот индекс (вместе с остальными на эту таблицу), но я не могу получить его ниже 50%.

Кроме того, я сделал резервную копию/восстановление базы данных на локальном компьютере, и у меня нет проблем с удалением - менее секунды.

Единственное, что я не сделал, это полностью удалить кластерный индекс и повторно добавить его. Это само по себе является проблемой, поскольку SQL Server не позволяет вам отбрасывать индекс PK, когда он ссылается на другие таблицы.

Любые идеи?

Update

я должен был включить это в моем оригинальном посте. В плане выполнения помещается «виноват» на удаление кластерного индекса - 70%. Из 13 таблиц, которые ссылаются на эту таблицу, в плане выполнения говорится, что ни один из них не превышает более 3% от общего запроса - почти все попытки поиска по индексу.

источник

2010-10-21 J.C.

Я просто сбился с толку в этот момент. Это довольно неприятно. –

Насколько велик файл данных? – ulty4life

Это около 3GB –

Ну, у меня есть ответ ...

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

То, что я решил сделать было следующее:

Добавить временный уникальный индекс (так SQL сервер позволит мне удалить кластерный индекс)
Удалить кластерный индекс.
Повторно добавить кластеризованный индекс.
Удалить временный уникальный индекс.

По существу, я удалил и добавил кластеризованный индекс. Единственное, что я могу убрать от этого, это то, что, возможно, часть индекса или там, где он был физически сохранен, был «поврежден» (я использую этот термин свободно).

источник

2010-10-26 01:55:55

Это хорошо, что вы делитесь с нами тем, что вы решили сделать. Но вы забыли упомянуть, каковы результаты ... –

@ vgv8 - Не проблема, я должен был включить это в свой ответ. Фрагментация на самом деле увеличилась с 50% до 66% (восстановление/реорганизация не может быть ниже), а время, затрачиваемое на выполнение запроса, снизилось примерно с 2 минут до 10 секунд (все еще слишком высокое). План выполнения не изменился. –

Если вы удалите строку, база данных должна проверить, что ни одна из 13 таблиц не ссылается на эту строку. Имеются ли достаточные индексы в столбцах внешнего ключа в тех других таблицах, которые ссылаются на таблицу, которую вы удаляете?

источник

2010-10-21 16:06:01

Было как раз сообщение о том же. Определенно посмотрите на план выполнения, чтобы выяснить, что создает узкое место. –

Good Point - я должен был включить это в мой оригинальный пост (я его обновлю). При этом, согласно плану выполнения, 70% операции относится к удалению кластерного индекса. Таблицы, на которые ссылаются почти все, имеют поиск, и ни один из них не потребляет более 3% от общего запроса. –

@Phile: Jeremiah выполнил резервное копирование и восстановление и не может воспроизвести проблему в локальном поле, что означает, что проверка ссылочной целостности не вызывает проблемы. – Codism

Возможно, стол заблокирован другим трудоемким процессом в процессе производства.

источник

2010-10-21 16:10:41 Codism

Мысль об этом, а также - пропустил профилировщик, чтобы определить возможные блокировки, но безрезультатно. На данный момент я ничего не нашел с блокировкой. –

Другая мысль, есть ли триггер удаления на столе? Может ли это быть причиной?

источник

2010-10-21 16:44:28 HLGEM

Хорошая мысль, но я уже думал об этом - никаких триггеров. –

SQL Server - Плохая производительность PK delete

ответ

Смежные вопросы