Видалення оператора в SQL відбувається дуже повільно

У мене є такі заяви, які вичерпують час:

DELETE FROM [table] WHERE [COL] IN ( '1', '2', '6', '12', '24', '7', '3', '5')

Я намагався робити по одному за таким чином:

DELETE FROM [table] WHERE [COL] IN ( '1' )

і поки що це 22 хвилини і все ще йде.

Таблиця містить 260 000 рядків і складається з чотирьох стовпців.

Хтось має ідеї, чому це буде так повільно і як це пришвидшити? У мене є не унікальний, некластеризований індекс на [COL], на якому я роблю WHERE. Я використовую SQL Server 2008 R2

оновлення: у мене немає тригерів на столі.

Речі, які можуть спричинити повільне видалення:

• видалення великої кількості записів
• багато індексів
• відсутні індекси зовнішніх ключів у дочірніх таблицях. (дякую @CesarAlvaradoDiaz за згадку про це в коментарях)
• тупикові ситуації та блокування
• тригери
• каскадне видалення (ці десять батьківських записів, які ви видаляєте, можуть означати видалення мільйонів дочірніх записів)
• Журнал транзакцій потребує зростання
• Багато іноземних ключів для перевірки

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

1. Вимкніть CONSTRAINT

   ALTER TABLE [TableName] NOCHECK CONSTRAINT ALL;

2. Вимкнути індекс

   ALTER INDEX ALL ON [TableName] DISABLE;

3. Індекс відновлення

   ALTER INDEX ALL ON [TableName] REBUILD;

4. Увімкнути CONSTRAINT

   ALTER TABLE [TableName] CHECK CONSTRAINT ALL;

5. Знову видаліть

Видалення великої кількості рядків може бути дуже повільним. Спробуйте видалити кілька за раз, наприклад:

delete top (10) YourTable where col in ('1','2','3','4')
while @@rowcount > 0
    begin
    delete top (10) YourTable where col in ('1','2','3','4')
    end

Профілактична дія

Перевірте за допомогою SQL Profilerосновної причини цієї проблеми. Можливо, Triggersпричина затримки виконання. Це може бути що завгодно. Не забудьте вибрати Database Nameта Object Nameпід час запуску, Traceщоб виключити сканування непотрібних запитів ...

Фільтрування імен баз даних

Таблиця / Збережена процедура / Фільтрування імен тригера

Коригувальні дії

Як ви вже сказали, ваша таблиця містить 260 000 записів ... і IN Predicateмістить шість значень. Зараз кожен запис здійснюється пошук 260 000 разів для кожного значення в IN Predicate. Натомість це має бути Внутрішнє приєднання, як показано нижче ...

Delete K From YourTable1 K
Inner Join YourTable2 T on T.id = K.id

Вставте IN Predicateзначення в Temporary TableабоLocal Variable

Якщо таблиця, з якої ви видаляєте, має тригери ДО / ПІСЛЯ ВИДАЛЕННЯ, щось там може спричинити затримку.

Крім того, якщо у вас є зовнішні ключі, що посилаються на цю таблицю, можуть відбутися додаткові ОНОВЛЕННЯ або ВИДАЛЕННЯ.

У моєму випадку статистика бази даних пошкодилася. Заява

delete from tablename where col1 = 'v1' 

зайняло 30 секунд, хоча відповідних записів не було, але

delete from tablename where col1 = 'rubbish'

побіг миттєво

біг

update statistics tablename

вирішено проблему

Можливо, інші таблиці мають обмеження FK для вашої [таблиці]. Отже, БД потрібно перевірити ці таблиці, щоб зберегти цілісність посилань. Навіть якщо у вас є всі необхідні індекси, що відповідають цим ФК, перевірте їх кількість.

У мене була ситуація, коли NHibernate неправильно створив дубльовані FK- файли на тих самих стовпцях, але з різними іменами (що дозволено SQL Server). Це різко уповільнило роботу оператора DELETE.

Перевірте план виконання цього оператора видалення. Подивіться, чи використовується пошук за індексом. Також що таке тип даних col?

Якщо ви використовуєте неправильний тип даних, змініть оператор оновлення (наприклад, з '1' на 1 або N'1 ').

Якщо використовується сканування індексу, розгляньте можливість використання підказки ..

[COL] - це справді поле символів, яке містить цифри, або ви можете позбутися одинарних лапок навколо значень? @Alex має рацію, що IN повільніше ніж =, тому, якщо ви можете це зробити, вам буде краще:

DELETE FROM [table] WHERE [COL] = '1'

Але краще все-таки використовувати числа, а не рядки для пошуку рядків (sql любить числа):

 DELETE FROM [table] WHERE [COL] = 1

Може спробувати:

 DELETE FROM [table] WHERE CAST([COL] AS INT) = 1

У будь-якому випадку переконайтеся, що у вас є індекс у стовпці [COL], щоб пришвидшити сканування таблиці.

Я прочитав цю статтю, вона була дуже корисною для усунення будь-яких незручностей

https://support.microsoft.com/en-us/kb/224453

це випадок очікування джерела КЛЮЧ: 16: 72057595075231744 (ab74b4daaf17)

-- First SQL Provider to find the SPID (Session ID)

-- Second Identify problem, check Status, Open_tran, Lastwaittype, waittype, and waittime
-- iMPORTANT Waitresource select * from sys.sysprocesses where spid = 57

select * from sys.databases where database_id=16

-- with Waitresource check this to obtain object id 
select * from sys.partitions where hobt_id=72057595075231744

select * from sys.objects where object_id=2105058535

Якщо ви видаляєте всі записи в таблиці, а не декілька вибраних, можливо, набагато швидше просто скинути та відтворити таблицю.

Перевіривши пакет SSIS (через те, що SQL Server виконує команди дуже повільно), який був встановлений у нашого клієнта приблизно за 5-4 роки до мого написання цього, я виявив, що були такі завдання: 1 ) вставити дані з XML-файлу в таблицю з назвою [Importbarcdes].

2) команда злиття в іншій цільовій таблиці, використовуючи як джерело згадану таблицю.

3) "видалити з [Імпорт-коди]", щоб очистити таблицю рядка, який був вставлений після прочитання файлу XML завданням пакета SSIS.

Після швидкої перевірки всіх операторів (SELECT, UPDATE, DELETE тощо) таблиці ImportBarcode, які мали лише 1 рядок, знадобилося приблизно 2 хвилини для виконання.

Розширені події показали дуже багато сповіщень про очікування PAGEIOLATCH_EX.

У таблиці відсутні індекси та не було зареєстровано тригерів.

Після ретельного вивчення властивостей таблиці, на вкладці «Зберігання» та в загальному розділі поле «Простір даних» показало більше 6 ГІГАБІТ місця, виділеного на сторінках.

Що трапилось:

Запит виконувався протягом великих порцій часу щодня протягом останніх 4 років, вставляючи та видаляючи дані в таблиці, залишаючи невикористані файли сторінок, не звільняючи їх.

Отже, це була основна причина подій очікування, які були зафіксовані розширеною сесією подій та повільно виконуваних команд на столі.

Запуск ALTER TABLE ImportBarcodes REBUILDвирішив проблему, звільнивши весь невикористаний простір. TRUNCATE TABLE ImportBarcodesзробив подібне, з тією лише різницею, що видалив усі файли сторінок та дані.

Давніша тема, але одна, як і раніше актуальна. Інша проблема виникає, коли індекс став фрагментованим настільки, що стає більшою проблемою, ніж допоміжною. У такому випадку відповіддю буде відновлення або скидання та відтворення індексу та повторне видалення оператора delete.

Як продовження відповіді Андомара вище, у мене був сценарій, коли перші 700 000 000 записів (близько 1,2 мільярда) оброблялись дуже швидко, обробляючи фрагменти в 25 000 записів в секунду (приблизно). Але тоді потрібно почати 15 хвилин, щоб зробити партію 25000. Я зменшив розмір шматка до 5000 записів, і він повернувся до своєї попередньої швидкості. Я не впевнений, який внутрішній поріг я досяг, але виправлення полягало в зменшенні кількості записів, щоб відновити швидкість.

відкрийте CMD і запустіть ці команди

NET STOP MSSQLSERVER
NET START MSSQLSERVER

це перезапустить екземпляр SQL Server. спробуйте запустити ще раз після вашої команди видалення

Я маю цю команду в пакетному сценарії і час від часу запускаю її, якщо у мене виникають такі проблеми. Звичайний перезапуск ПК не буде таким самим, тому перезапуск екземпляра є найефективнішим способом, якщо у вас виникають проблеми з вашим сервером SQL.