Запрос интервью сервера SQL по индексу?

Question

Я получил один вопрос от NET, но не нашел подходящего решения, может ли кто-нибудь сказать , что с этим не так?

Учитывая эту структуру и индекс таблицы, в чем проблема с последующим запросом?

CREATE TABLE dbo.IndexQ (
ID int IDENTITY(1, 1) NOT NULL, 
TestBit bit NOT NULL 
) 
GO 

CREATE NONCLUSTERED INEX IX_IndexQ_TestBit ON dbo.IndexQ (TestBit) 
GO 

* Insert some rows where some bits are 0 and some are 1... 

SELECT * 
FROM dbo.IndexQ 
WHERE TestBit = 1 
* What's the problem with this query? 

Answer 1

Я полагаю, что проблема в вашем индексе NONCLUSTERED на поле бит. Если у вас большая таблица, вы не должны создавать индекс в поле бит, потому что тогда у него больше записей, тем менее эффективный индекс будет работать, но больше даты вы будете использовать на нем.

См https://dba.stackexchange.com/questions/12888/should-i-index-a-bit-field-in-sql-server

Answer 2

1) Общая практика для создания индекса является то, что первый столбец индекс должен быть столбец с более высокой селективности/низкой плотности (плотность показывает, сколько уникальных значений находятся в пределах столбца или набор столбцов). Более низкая плотность (означает множество уникальных значений) лучше, потому что это способствует Index Seek по сравнению с Index Scan. В этом случае индекс на столбце BIT означает более высокую плотность, что благоприятствует Index Scan.

2) Но SELECT * заставляет сервер возвращать все столбцы, а не только значения (TestBit) от TestBit. Это означает, что для этого запроса SELECT индекс не распространяется (не включает все столбцы, необходимые для этого запроса).

3) Более высокая плотность (1) плюс индекс без покрытия (2) означает, что, скорее всего, "tipping point" для этого индекса заставит сервер не использовать этот индекс и вместо этого выбрать (весьма вероятно) Сканирование таблицы.

Это означает, что этот показатель не является полезным.