Простой SQL-обновление выполняется очень медленно

Question

SQL Server 2008 R2.

Выполнение простой команды обновления, которая выглядит, как этот

UPDATE [group_mtm] SET group = foobar where user in (u1,u2,u3,...u19) 

запрос только обновление 1 строка, но занимает свыше 2-х секунды. Это таблица атрибутов 2, используемая как соединение много-ко-многим. В настоящее время в таблице представлено около 300 записей. Основной ключ = составной ключ для атрибутов группы и пользователя.

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

Table 'foobar'. Scan count 1, logical reads 21214, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Worktable'. Scan count 1664, logical reads 42674, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'mail_mtm'. Scan count 1, logical reads 428, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'event'. Scan count 1, logical reads 893, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'user'. Scan count 0, logical reads 91, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'addresses'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'mail'. Scan count 1, logical reads 79, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'links'. Scan count 1, logical reads 18, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'group_mtm'. Scan count 20, logical reads 120, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(20 row(s) affected) 

(1 row(s) affected) 

Единственное, что я могу вспомнить, что Foobar является и индексируются просмотра, и, возможно, затраты тратятся на его поддержание, поэтому я проверил план выполнения; он действительно вступает в игру (но только 11% стоимости).

Почему это занимает 2+ секунд?

Что я пересматриваю здесь?

В плане выполнения указано, что я добавляю индекс на событие, но событие не должно даже участвовать здесь, и его стоимость составляет всего 13%.

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

Кто-то, вероятно, собирается дать мне совет мудреца об индексированных представлениях, увеличивая общую накладную БД; но все другие операции, идущие в туалет, кажутся довольно крутой ценой для более быстрого поиска запросов на некоторые запросы, предоставляемые индексированными представлениями.

Учите меня; пожалуйста и спасибо!

план выполнения XML является слишком большим, чтобы получить возможность отправлять как текст, и я не вижу для вкладывания, так Pastebin на помощь: http://pastebin.com/BgjBxLfc

Answer 1

Это может быть не весь ответ, но расширить запрос SQL для дальнейшего укажите имена полей: [таблица]. [поле]. Я предполагаю, что «группа» - это поле в group_mtm, но похоже, что вы пытаетесь присвоить ему таблицу «foobar»?