Ускорение удалений, имеющих соединения

Я использую хранимую процедуру для удаления данных из двух таблиц:

delete from TESTING_testresults from TESTING_testresults inner join TESTING_QuickLabDump on TESTING_QuickLabDump.quicklabdumpid = TESTING_TestResults.quicklabdumpid where TESTING_quicklabdump.[Specimen ID][email protected] delete from TESTING_QuickLabDump from TESTING_Quicklabdump where [specimen id][email protected] 

одна таблица имеет длину 60 м, а другая – около 2 м. строк

процедура занимает около 3 секунд.

есть ли способ ускорить это? возможно, используя EXISTS ?

значение IF EXISTS...THEN DELETE – потому что удаление не должно происходить каждый раз

что-то вроде этого

если @specimen exists в TESTING_QuickLabDump то выполните процедуру с двумя удалениями

Спасибо !!!

Для таблицы с 60-мильными рядами я бы определенно рассмотрел разделение данных по горизонтали и / или по вертикали. Если это данные, чувствительные к времени, тогда вы должны перенести старые данные в таблицу предыстории. Это, как правило, первая и самая очевидная вещь, которую люди делают, поэтому я бы предположил, что если бы это было возможно, вы бы уже это сделали.

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

Если вы действительно хотите настроить скорость, вы должны изучить возможность получения более быстрого жесткого диска и немного узнать о работе жестких дисков. Независимо от того, хранятся ли данные во внутренней или внешней части hd, например, скорость доступа незначительна. И твердотельные жесткие диски прошли долгий путь, чтобы вы могли изучить их.

Переписывание запроса, вероятно, не поможет ускорить это. Используйте профилировщик, чтобы выяснить, какие части запроса медленны. Для этого сделайте его профилировщиком выведите план выполнения . Затем попробуйте добавить соответствующие индексы. Возможно, одна или обе таблицы могут использовать индекс над [specimen id] .

Помимо индексирования «очевидных» полей, также смотрите в схеме базы данных и проверьте, есть ли у вас какие-либо FOREIGN KEY, чьи ON DELETE CASCADE или SET NULL могут быть вызваны вашим удалением (в отличие от Oracle, MS SQL Server будет показывать их в плане выполнения ). К счастью, это обычно довольно легко исправить, индексируя конечную точку дочернего элемента FOREIGN KEY.

Также проверьте, есть ли у вас дорогие триггеры.

  • Предложение Sql IN замедляет работу
  • заполнять IDataReader без отражения с помощью любого (заданного) объекта Collection
  • Низкая производительность при использовании linq и INTERSECT / EXCEPT в небольших коллекциях
  • Самый эффективный способ SELECT строк WHERE ID EXISTS IN во второй таблице
  • Простой внутренний вход в 2 таблицы, что приводит к неправильным оценкам строк и низкой производительности
  • Эксплуатационная производительность SQL Server 2008 в производственной среде?
  • Стратегии проверки ISNULL на varbinary fields?
  • Может ли EXPLAIN предоставить больше, чем просто план запроса?
  • Минимальное и максимальное использование памяти в SQL Server?
  • Почему это заявление Sql (с 2 присоединениями таблицы) занимает 5 минут?
  • EF 6 против относительной производительности EF 5 при развертывании в IIS8
  • Давайте будем гением компьютера.