2014-11-28 7 views
1

У меня есть следующий оператор SQL, который я хотел бы сделать более эффективным. Просматривая план выполнения, я вижу, что есть кластерное сканирование индексов на @newWebcastEvents. Есть ли способ сделать это в поисках? Или есть другие способы, которыми я могу сделать ниже более эффективным?Индексная проверка в операторе обновления SQL

declare @newWebcastEvents table (
    webcastEventId int not null primary key clustered (webcastEventId) with (ignore_dup_key=off) 
) 

insert into @newWebcastEvents 
select wel.WebcastEventId 
from WebcastChannelWebcastEventLink wel with (nolock) 
where wel.WebcastChannelId = 1178 

Update WebcastEvent 
set WebcastEventTitle = LEFT(WebcastEventTitle, CHARINDEX('(CLONE)',WebcastEventTitle,0) - 2) 
where 
WebcastEvent.WebcastEventId in (select webcastEventId from @newWebcastEvents) 
+0

его только временную таблицу и не только первичный ключ. Стол небольшой, только до 15 строк. таблица, которую я обновляю, может содержать тысячи строк. – user3284707

+0

В WebcastChannelWebcastEventLink имеется около 5000 строк, из них в таблице отображено около 15 строк этой таблицы. @newWebcastEvents – user3284707

ответ

1

Переменная @newWebcastEvents таблица содержит только только один столбец, и вы просите всех строк этой переменной таблицы в этом пункте, где:

where 
    WebcastEvent.WebcastEventId in (select webcastEventId from @newWebcastEvents) 

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

Я вообще не думаю, что это проблема с производительностью.

Поиск индекса полезен, если вам нужно выбрать очень небольшое количество строк (< = 1-2% от исходного количества строк) из большой таблицы. Затем, проходя через дерево навигации с кластеризованным индексом и находить те несколько задействованных строк, имеет гораздо больший смысл, чем сканирование всей таблицы. Но здесь, с одной int колонки и 15 строк -> это абсолютно бессмысленно искать, это будет гораздо быстрее просто читать эти 15 int значения в одном сканировании и сделать с ней ...

Update: не уверен, если это делает никакой разницы с точки зрения производительности, но лично я, как правило, предпочитают использовать присоединяется, а не подзапросы для «соединяющих» двух таблиц:

UPDATE we 
SET we.WebcastEventTitle = LEFT(we.WebcastEventTitle, CHARINDEX('(CLONE)', we.WebcastEventTitle, 0) - 2) 
FROM dbo.WebcastEvent we 
INNER JOIN @newWebcastEvents nwe ON we.WebcastEventId = nwe.webcastEventId 
+0

О, хорошо, хорошо, привет. Этот запрос не займет много времени, я просто пытаюсь улучшить свои знания. Мне сказали попробовать и избегать сканирования индексов в моих запросах, поэтому просто пытались исправить это, но это имеет смысл. Не могли бы вы сказать, что это самый эффективный способ сделать то, что я пытаюсь сделать? – user3284707

+0

@ user3284707: да, я бы также рекомендовал избегать сканирования индексов - на самом деле ** больших таблиц **, например. 100'000 строк или более - если вам нужно извлечь только несколько строк (1-2% от общего числа) из этих таблиц. Но 15 значений 'int' - это ** 60 байт **, что намного меньше, чем 8K, что одна страница - и SQL Server всегда загружается на основе страниц ...... –

+0

Большое спасибо за это, я буду посмотрите на изменение моего обновления, если это считается лучшей практикой. Спасибо за вашу помощь. – user3284707

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