У меня есть база данных SQL Server 2005, и я попробовал размещение индексов в соответствующих полях для ускорения УДАЛЕНИЯ
записей из таблицы с миллионами строк ( big_table
имеет только 3 столбца), но теперь DELETE
время выполнения даже на больше ! (1 час вместо 13 минут, например)
У меня есть связь между таблицами, и столбец, по которому я фильтрую мой DELETE
, находится в другой таблице. Например
DELETE FROM big_table
WHERE big_table.id_product IN (
SELECT small_table.id_product FROM small_table
WHERE small_table.id_category = 1)
Между прочим, я также пробовал:
DELETE FROM big_table
WHERE EXISTS
(SELECT 1 FROM small_table
WHERE small_table.id_product = big_table.id_product
AND small_table.id_category = 1)
, и хотя кажется, что он работает немного быстрее, чем первый, он все же намного медленнее с индексами, чем без него.
Я создал индексы для этих полей:
big_table.id_product
small_table.id_product
small_table.id_category
Мой .ldf-файл сильно увеличивается во время DELETE
.
] Почему мои запросы DELETE
выполняются медленнее, когда у меня есть индексы в моих таблицах? Я думал, что они должны выполняться быстрее.
UPDATE
Хорошо, похоже, что индексы будут работать медленнее. огромный DELETE
, потому что индекс должен быть обновлен. Хотя я до сих пор не понимаю, почему он не может УДАЛИТЬ
все строки сразу и просто обновить индекс один раз в конце.
Я был под впечатлением от некоторых моих чтений эти индексы ускорили бы DELETE
за счет ускорения поиска полей в предложении WHERE
.
"
Нужно ли мне делать что-то особенное с моими индексами после того, как я СОЗДАЮ
их, чтобы они работали правильно?
Индексы ускоряют поиск - как индекс в конце книги.
Операции, изменяющие данные (например, DELETE), выполняются медленнее, поскольку они связаны с манипулированием индексами. Рассмотрим тот же индекс в конце книги. При добавлении, удалении или изменении страниц у вас будет больше работы, потому что вам придется обновлять индекс.
Я согласен с Комментарий Боба выше - если вы удаляете большие объемы данных из больших таблиц, удаление индексов может занять некоторое время, помимо удаления данных, это затраты на ведение бизнеса. Поскольку он удаляет все данные, вы вызываете события переиндексации.
Что касается роста файла журнала; если вы ничего не делаете со своими лог-файлами, вы можете переключиться на Простое ведение журнала; но я настоятельно прошу вас прочитать о влиянии, которое может оказать на ваш ИТ-отдел, прежде чем вы что-то измените.
Если вам нужно делать удаление в реальном времени; часто бывает полезно пометить данные как неактивные непосредственно в таблице или в другой таблице и исключить эти данные из запросов; затем вернитесь позже и удалите данные, когда пользователи не смотрят на песочные часы.Есть вторая причина для того, чтобы скрыть это; если вы удаляете много данных из таблицы (что я предполагаю, исходя из проблемы с файлом журнала), вы, вероятно, захотите выполнить indexdefrag, чтобы реорганизовать индекс; делать это в нерабочее время - лучший вариант, если вам не нравятся пользователи по телефону!
Вы также можете попробовать расширение TSQL для синтаксиса DELETE и проверить, улучшает ли оно производительность:
DELETE FROM big_table
FROM big_table AS b
INNER JOIN small_table AS s ON (s.id_product = b.id_product)
WHERE s.id_category =1