Когда создать новый Индекс SQL Server?
printf возвращает количество напечатанных символов.
printf("%*c", N, C); печатает N-1 пробелы, за которыми следует символ C.
В общем случае printf печатает N - length_of_text ] (если это число > 0, нулевые пробелы в противном случае), за которым следует текст. То же самое относится и к номерам.
, поэтому
return printf("%*c%*c", x, ' ', y, ' ');
печатает пробел с префиксом x минус length_of_space других пробелов (x-1), затем делает то же самое для y. Это делает 4+5 пробелы в вашем случае. Затем printf возвращает общее количество напечатанных символов. 9.
printf("%d",add(4,5));
Это printf печатает целое число, возвращаемое функцией add(), 9.
По умолчанию , printf выравнивается по правому краю (пробелы перед текстом). Чтобы [ []
- перед * , например %-*s, или %-12s, %-6d
7 ответов
Лучший ответ на это должен представить Ваши запросы и видеть, улучшает ли индекс Ваши запросы. Трудность при ответе на это состоит в том, что почти невозможно обобщить поведение оптимизатора запросов.
Тем не менее эмпирическое правило - то, если Ваша селективность составит 10% или меньше на данном запросе на таблице, то Вы, скорее всего, извлечете выгоду из индекса. Таким образом в Вашем примере, Вы могли бы преимущество от индекса, если Ваши значения равномерно распределяются. Однако полагая, что Ваша таблица является маленькой, таким образом, Ваше повышение производительности могло бы быть незначительным.
Это не жесткое правило, поскольку существует много факторов, которые могут изменить 10%-е число, включая использование кластеризованных или других индексных типов размер строк, если некоторые столбцы, не встроенные, структура запроса, и т.д.
Также имеет в виду, существует значительная потеря производительности для вставки в таблицу с индексом. Если эта таблица часто обновляется или добавляется, повышение скорости от индекса может отрицаться, медленнее вставляет и обновляет.
См. статью MSDN о Сканирование таблицы по сравнению с Индексным доступом .
Редактирование: Как другие указали, Ваш запрос может извлечь выгоду из индекса при выполнении запросов агрегирования, таких как подсчет количества раз появляется, конкретное значение. Можно также извлечь выгоду если Вы часто вид на конкретном столбце.
создание индекса на
BITстолбец является ненужным.
Вы были бы удивлены.
я должен был создать индекс, включающий немного столбца для запроса как:
SELECT foo.Name FROM foo WHERE foo.Active = 1
в таблице было приблизительно 300 000 строк все же.
В столбце Вы предлагаете, было бы объяснение для создания ссылки или справочной таблицы для данных для предотвращения избыточности данных. Это сделало бы Ваш столбец внешним ключом, указывающим на PK новой справочной таблицы.
Все столбцы внешнего ключа должны быть индексированы.
Иначе, я постарался бы не помещать индекс при нормальных условиях на таком столбце.
Индексы с низкой кардинальностью очень проблематичны. Если существует только несколько возможных значений, SQL Server почти всегда индексные сканирования, независимо от того, что пропорции.
Пример: у меня была таблица с полем State, которое только приняло значения "A", "N", и "R" (для Активного, Нового, и На пенсии.) Обычно Вы приблизились бы к условию, где 95% были "R", 4 +, % был "A", и некоторые были "N". ВЫБЕРИТЕ, ГДЕ состояние = 'N' был бы сканирование таблицы, несмотря ни на что.
, НО - существует довольно новый индексный тип, названный Фильтрованный Индекс, , который наконец обрабатывает это условие. Также удобно, когда Вы хотите исключить записи с Нулевыми значениями.
James попал в точку. Я просто добавлю, что даже немного столбца могло бы извлечь выгоду из индекса в зависимости от того, как Вы используете таблицу. Например, если необходимо считать количество строк, которые имеют 1 много раз в течение дня, индекс, там могло быть полезным. Индексы не всегда о нахождении единственной записи - они могут также использоваться для агрегирований.
Я сказал бы, что все это зависит от того, как таблица используется и полные системные требования. Например, если бы это - часть большого СОЕДИНЕНИЯ, и родитель является огромной таблицей типа отчета затем, Вы хотели бы индекс наверняка. Если это является относительно маленьким по сравнению с Вашими другими таблицами в базе данных, и это в большой степени вставляется и редко читается, то индекс не, вероятно, желаем.
, Но, объемом операции среди всей базы данных по сравнению с имеющимися ресурсами, которые будут выделены, является ключевой фактор решения. Это - как эта таблица + возможный индекс ведет себя во всей системе по сравнению со всеми Вашими другими таблицами и их требованиями. Если Вы не сохраняете большое изображение в памяти, Вы могли бы уничтожить целую систему путем попытки применить некоторое произвольное правило просто ради применения произвольного правила.
Необходимо также тщательно исследовать индексы, если Вы начинаете испытывать мертвые блокировки среди запросов, обычно между ВЫБОРОМ и ВСТАВЛЕНИЕМ/ОБНОВЛЕНИЕМ. Плохо выбранный индекс может способствовать мертвым блокировкам, поскольку не может, имея индекс вообще. См. эта база знаний статья для получения дополнительной информации. Обычно, добавление индекса или изменение его включенных столбцов помогут разрешить такие мертвые блокировки. Обязательно исследуйте план запросов затронутых запросов.