Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
MS SQL 2008 R2.

Тема не нова, но просмотр нескольких тем из поиска не помог внести понимание.
Ситуация
Был некий запрос в вьюхе. В один прекрасный момент оно вдруг начало все тормозить.
Упрощенно запрос такой:
select m.C_MOVE, li.PRICE  from L_MOVE m left join L_ITEMS1 li on m.C_ITEM_INCOME_DOC=li.C_ITEMS
where m.MOVE_DATE>='20111212'

--
C_ITEMS - первичный ключ в таблице L_ITEMS1. В самой таблице около миллиона записей.
Смотрю план - узкое место "Clustered Index Scan" по c_items. Рекомендует создать некластерный индекс по нему же.
Создал, - проблема ушла.
Вопрос, возможно порожденный моей безграмотностью, - а вообще с какого перепуга оптимизатор вдруг решает что ему нужно сканировать кластерный индекс? Какой тут физический смысл?
16 дек 11, 12:27    [11776849]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
Вопрос, возможно порожденный моей безграмотностью, - а вообще с какого перепуга оптимизатор вдруг решает что ему нужно сканировать кластерный индекс?

сканирование кластерного индекса == сканирование таблицы
16 дек 11, 12:38    [11776895]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
McCar
Вопрос, возможно порожденный моей безграмотностью, - а вообще с какого перепуга оптимизатор вдруг решает что ему нужно сканировать кластерный индекс?

сканирование кластерного индекса == сканирование таблицы

Ну не настолько я безграмотный чтобы этого не понимать.
:-)
Но таблица справа от Left Join-а, я не могу вообразить, в какой ситуации при таком количестве записей в таблице сканирование может быть выгоднее поиска. Вот и хочу понять - это оптимизатор сбрендил или я чего то глубоко недопонимаю.
16 дек 11, 12:46    [11776930]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
Но таблица справа от Left Join-а, я не могу вообразить, в какой ситуации при таком количестве записей в таблице сканирование может быть выгоднее поиска.

Вот вы откуда знаете, что выгоднее ?
Вы подсчитали в уме количество записей вообще, количество записей попадающих под соединение ?
Вы выбрали такую же стратегию соединения как и сервер ?
Если в L_MOVE тоже миллион записей, то делать миллион раз поиск по индексу тоже по-вашему выгодно ?
16 дек 11, 12:50    [11776955]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Вдогонку.
Естественно, все ключи интовые, так что вариант
Why is SQL Server doing a clustered index scan?
- не мой случай.
16 дек 11, 12:50    [11776959]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
McCar
Но таблица справа от Left Join-а, я не могу вообразить, в какой ситуации при таком количестве записей в таблице сканирование может быть выгоднее поиска.

Вот вы откуда знаете, что выгоднее ?
Вы подсчитали в уме количество записей вообще, количество записей попадающих под соединение ?
Вы выбрали такую же стратегию соединения как и сервер ?
Если в L_MOVE тоже миллион записей, то делать миллион раз поиск по индексу тоже по-вашему выгодно ?


В L_MOVE - около десяти миллионов.
Тогда другая постановка вопроса - допустим миллион раз поиск по кластерному индексу невыгодно. Но почему тогда в этой же ситуации - выгодно по некластерному?
16 дек 11, 12:56    [11776982]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Видимо в индексе нету результирующих полей. И после того как по индексу будут найдены нужные записи, все равно придется потом прочитать большое количество страниц из таблицы(при том возможно взять придется по одной записи со страницы) . Оптимизатор считает что ему уж тогда проще сразу все страницы из таблицы взять и на заморачиваться с индексом. Операция в плане называется key lookup - ее надо стараться избегать.
16 дек 11, 12:56    [11776984]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Я кажется не внимательно прочитал вопрос.
Покажите план.
16 дек 11, 13:04    [11777009]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
McCar
Glory
пропущено...

Вот вы откуда знаете, что выгоднее ?
Вы подсчитали в уме количество записей вообще, количество записей попадающих под соединение ?
Вы выбрали такую же стратегию соединения как и сервер ?
Если в L_MOVE тоже миллион записей, то делать миллион раз поиск по индексу тоже по-вашему выгодно ?


В L_MOVE - около десяти миллионов.
Тогда другая постановка вопроса - допустим миллион раз поиск по кластерному индексу невыгодно. Но почему тогда в этой же ситуации - выгодно по некластерному?
Все, понял вопрос)
Клястерный индекс - это все поля таблицы. В итоге на одной странице меньше ключей.
16 дек 11, 13:31    [11777192]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Deff
Я кажется не внимательно прочитал вопрос.
Покажите план.


К сообщению приложен файл. Размер - 134Kb
16 дек 11, 13:46    [11777318]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Т.е. оптимизатор в вашем случае считает так от лучшего к худшему:

1. noncluster index seek
2. cluster index scan
3. cluster index seek


Почему 2 лучше чем 3, вы уже поняли.

1 лучше чем 3, так как количество ключей на странице больше, в итоге найти конкретную запись получится быстрее.

Кроме того, возможно, оптимизатор хочет сделать noncluster index scan.
16 дек 11, 14:02    [11777472]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
Тогда другая постановка вопроса - допустим миллион раз поиск по кластерному индексу невыгодно. Но почему тогда в этой же ситуации - выгодно по некластерному?

Вы статистику своих таблиц давно обновляли ?
16 дек 11, 14:02    [11777473]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Glory
Member

Откуда:
Сообщений: 104751
А где в плане key lookup по L_ITEMS1 ?
Там hash join те одноразовый скан таблицы для поиска совпадений
16 дек 11, 14:04    [11777488]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
И вы не сказали еще сколько записей в L_ITEMS1.
А так же несколько широкая таблица L_ITEMS1. Какой размер одной записи?
16 дек 11, 14:19    [11777639]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Джентельмены, дико извиняюсь, пятничное помутнение сознания, я вам мозги напрасно морочил..
Нет там кластерного по c_item. И никакого нет. Отдельная тема, всегда ли оно так было или чьи то шаловливые ручки, но это уже явно не тема форума.
:-)
Все равно спасибо, немного освежил свои скудные здания по оптимизации запросов.
16 дек 11, 14:29    [11777744]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
Glory
Member

Откуда:
Сообщений: 104751
McCar
Джентельмены, дико извиняюсь, пятничное помутнение сознания, я вам мозги напрасно морочил..
Нет там кластерного по c_item. И никакого нет.

Кластерный индекс там есть все же. И судя по имени все же по ПК
16 дек 11, 14:31    [11777775]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
McCar
Member

Откуда: Саратов
Сообщений: 778
Glory
McCar
Джентельмены, дико извиняюсь, пятничное помутнение сознания, я вам мозги напрасно морочил..
Нет там кластерного по c_item. И никакого нет.

Кластерный индекс там есть все же. И судя по имени все же по ПК

Совершенно верно, но по другому полю - C_MOVE, которое ссылается на L_MOVE.С_MOVE, тоже уникальному.
16 дек 11, 14:42    [11777900]     Ответить | Цитировать Сообщить модератору
 Re: Clustered Index Scan по первичному ключу: с чего бы вдруг..  [new]
1d0
Member

Откуда: инфа100%
Сообщений: 2521
хочеш seek ну так и скажу ему with forceseek
16 дек 11, 17:28    [11779517]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить