Не обновил статистику по таблице
DBCC UPDATE STATISTICS [dbo].[Events]

leshik писал(а) 25. Августа 2010 :: 08:46:

Не помогает. перестроение/реорганизацию тоже пробовал.

Цитата:

Во всей таблице было 10000 записей. Столбцов - 9 шт. Неужели полное сканирование таблице дешевле поиска столбца?

Про поля в индексе:
у меня в отборе BaseId будет всегда (это ИД базы), т.е. это поле должно быть во всех индексах и желательно самое последнее, т.к. остальные поля дают бОльшую избирательность.
Я правильно мыслю?

А кластерный индекс то у тебя создан по таблице?
попробуй

CREATE CLUSTERED INDEX [idx_ObjectFullID] ON [dbo].[Events]
(
	[BaseID] ASC,
	[ObjectFullID] ASC
) 

и никаких INCLUDE ([UserID]) уже не надо.

Z1 писал(а) 26. Августа 2010 :: 11:31:

Ну.. с точки зрения пользователя, кластерный индекс в SQL Server не обязан быть уникальным.. 

Связка [BaseID]-[ObjectFullID] в этой таблице может повторяться бесконечное число раз.
Пока добавил в INCLUDE столбцы, которые мне вроде как должны понадобиться, и успокоился.

Z1 писал(а) 26. Августа 2010 :: 12:02:

"В SQL Server кластерный индекс является уникальным индексом по определению. Это означает что все ключи записей должны быть уникальные. Если существуют записи с одинаковыми значениями, SQL Server делает их уникальными, добавляя номера из внутреннего (невидимого снаружи) счетчика."
http://www.sql.ru/articles/mssql/03013101indexes.shtml#3

ИМХО INCLUDE - это решение для частного случая, когда под определенный очень важный запрос требуется свой индекс и некий набор полей.
А когда любое обращение к таблице делает фильтрацию по [BaseID] и [ObjectFullID] лучше создать кластерный индекс.

"запись может быть найдена либо по row ID либо по кластерному ключу. Это важное замечание, поскольку row ID или кластерный ключ будут сохраняться внутри не кластерного индекса и использоваться для получения реальных данных из записей."