Простое обновление 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 слишком велик, чтобы публиковать его в виде текста, и я не вижу возможности прикрепить его, поэтому вставьте его на помощь: http://pastebin.com/BgjBxLfc

Answer 1

Это может быть не полный ответ, но разверните запрос sql, чтобы уточнить имена полей: [таблица].[Поле]. Я предполагаю, что 'group' - это поле в group_mtm, но похоже, что вы пытаетесь присвоить ему таблицу 'foobar'?