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

Откуда:
Сообщений: 24
Добрый день. Пытаюсь разобраться в планах запроса. Есть таблица Test
CREATE TABLE [dbo].[Test](
	[Id] [int] NOT NULL,
	[val] [int] IDENTITY(1,1) NOT NULL,
	[val1] [nvarchar](50) NOT NULL,


Первое поле Primary Key с кластерным индексом, на второе повешен некластерный индекс
CREATE NONCLUSTERED INDEX [IX_Test_val] ON [dbo].[Test] 

Выполняем запрос с фильтром по второму полю:
SELECT *
  FROM [Test2].[dbo].[Test]
  where [val] = 5

Насколько я понял из теории sql должен по некластерному индексу найти все строки удовлетворяющие фильтру и затем вывести все эти строки. Тогда почему идет clustered index scan?

Картинка с другого сайта.

А если убрать из результирующего Select поле val1, тогда уже будет IndexSeek

Модератор: Тема перенесена из форума "Работа".


Сообщение было отредактировано: 26 авг 12, 22:22
26 авг 12, 22:22    [13066667]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
NewGuy123
Насколько я понял из теории sql должен по некластерному индексу найти все строки удовлетворяющие фильтру и затем вывести все эти строки. Тогда почему идет clustered index scan?


Что бы "вывести все эти строки", их нужно тоже найти.

То есть должно делаться 2 поиска - сначала ищем по [val] значения [Id], потом по ним по кластерному индексу ищем записи с полем [val1]

Видимо, количество записей и статистика таковы, что вместо такого сложного пути сервер решает просто просканировать таблицу
NewGuy123
А если убрать из результирующего Select поле val1, тогда уже будет IndexSeek
Тогда уже не нужно искать записи второй раз, поскольку поле [val1] не требуется, а поле [Id] всегда включено в индекс по полю [val], поэтому можно просто использовать этот индекс, даже независимо от статистики (только выбрав index seek или index scan).
26 авг 12, 23:12    [13066791]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
NewGuy123
Member

Откуда:
Сообщений: 24
alexeyvg
NewGuy123
Насколько я понял из теории sql должен по некластерному индексу найти все строки удовлетворяющие фильтру и затем вывести все эти строки. Тогда почему идет clustered index scan?


Что бы "вывести все эти строки", их нужно тоже найти.

То есть должно делаться 2 поиска - сначала ищем по [val] значения [Id], потом по ним по кластерному индексу ищем записи с полем [val1]

Видимо, количество записей и статистика таковы, что вместо такого сложного пути сервер решает просто просканировать таблицу
NewGuy123
А если убрать из результирующего Select поле val1, тогда уже будет IndexSeek
Тогда уже не нужно искать записи второй раз, поскольку поле [val1] не требуется, а поле [Id] всегда включено в индекс по полю [val], поэтому можно просто использовать этот индекс, даже независимо от статистики (только выбрав index seek или index scan).


Про два запроса я знаю. А вот про статистику не подумал - таблица пустая была. Действительно если ее наполнить - запрос становится нормальным. Спасибо.

Картинка с другого сайта.
26 авг 12, 23:35    [13066853]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
squid
Member

Откуда: LA
Сообщений: 590
alexeyvg,
Вы правы, я только перефразирую.

автор
Видимо, количество записей и статистика таковы, что вместо такого сложного пути сервер решает просто просканировать таблицу

100%

План со сканированием более эффективен поскольку он дешевле в данном случае.
Следует проверить селективность предиката. т.е. сколько процентов строк с [val] = 5. Как правило план со сканом становится дешевле сика если селективность >8-10%.

Чтобы убедится в правоте оптимизатора (скан - лучший выбор)
выполните

SELECT *
FROM [Test2].[dbo].[Test]
where [val] = 5
option(table hint(Test2,forceseek))




и сравните стоимость планов
27 авг 12, 00:34    [13067057]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
NewGuy123
Member

Откуда:
Сообщений: 24
squid
alexeyvg,
Вы правы, я только перефразирую.

автор
Видимо, количество записей и статистика таковы, что вместо такого сложного пути сервер решает просто просканировать таблицу

100%

План со сканированием более эффективен поскольку он дешевле в данном случае.
Следует проверить селективность предиката. т.е. сколько процентов строк с [val] = 5. Как правило план со сканом становится дешевле сика если селективность >8-10%.

Чтобы убедится в правоте оптимизатора (скан - лучший выбор)
выполните

SELECT *
FROM [Test2].[dbo].[Test]
where [val] = 5
option(table hint(Test2,forceseek))




и сравните стоимость планов


Подскажите, пожалуйста, - на какой cost из всех в плане необходимо уделять внимание?
И вообще как понять быстро или медленно будет выполнен запрос? К примеру без индекса в таблице у меня
Estimated I/O Cost 0,03 - это много или мало?
27 авг 12, 10:36    [13067872]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
NewGuy123
Подскажите, пожалуйста, - на какой cost из всех в плане необходимо уделять внимание?
И вообще как понять быстро или медленно будет выполнен запрос? К примеру без индекса в таблице у меня
Estimated I/O Cost 0,03 - это много или мало?
Это просто сравнительные величины, простым смертным их абсолютные значения ни о чём не скажут :-)
27 авг 12, 11:08    [13068031]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
NewGuy123
Member

Откуда:
Сообщений: 24
alexeyvg
NewGuy123
Подскажите, пожалуйста, - на какой cost из всех в плане необходимо уделять внимание?
И вообще как понять быстро или медленно будет выполнен запрос? К примеру без индекса в таблице у меня
Estimated I/O Cost 0,03 - это много или мало?
Это просто сравнительные величины, простым смертным их абсолютные значения ни о чём не скажут :-)


Тогда вопрос - из плана запроса можно понять долго(скажем больше 2 секунд) или быстро(меньше 2х секунд) выполняется запрос?
27 авг 12, 11:13    [13068062]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
NewGuy123
Member

Откуда:
Сообщений: 24
up
27 авг 12, 16:21    [13070981]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
gang
Member

Откуда:
Сообщений: 1394
NewGuy123, В общем случае нет. В плане приводятся цифры потребления ресурсов (IO и CPU например) в попугаях. Сколько занимает
обработка 1 попугая зависит от железа, загрузки и т.п. Так, что глядя на пару планов можно только сказать хуже\лучше (примерно).
Если нужны конкретные значения по времени используйте например set statistics time on при отладке\оптимизации.
27 авг 12, 16:57    [13071302]     Ответить | Цитировать Сообщить модератору
 Re: План запроса по индексированному полю  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
NewGuy123
alexeyvg
пропущено...
Это просто сравнительные величины, простым смертным их абсолютные значения ни о чём не скажут :-)

Тогда вопрос - из плана запроса можно понять долго(скажем больше 2 секунд) или быстро(меньше 2х секунд) выполняется запрос?
Я же говорю - абсолютные значения ни о чём не скажут.
27 авг 12, 17:46    [13071670]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить