Причина подсчета некластеризованного индекса в Sql Server - PullRequest
3 голосов
/ 22 ноября 2010

Почему у нас есть 249 некластеризованных индексов в SQL Server 2005?почему не 240 или 300?и тот же вопрос для sql server 2008, почему 999?Почему не 800 или 1000?

Ответы [ 5 ]

5 голосов

Они делают довольно (округленные) цифры ...

SQL Server 2005: 1 Кластерный индекс + 249 Некластеризованные индексы = 250 индексов на таблицу

SQL Server2008: 1 Кластерный индекс + 999 некластеризованных индексов = 1000 индексов на таблицу

Обновление:
Вы должны были спросить, почему 999 в SQL Server 2008.
Это было объяснено вответ на мой вопрос .Это увеличение было объяснено введением отфильтрованных индексов в SQL Server 2008.

Тип данных index_id в sysindexes означает :

  • 0 для кучи
  • 1 - кластерный индекс
  • > 1 некластеризованный
  • > = 3200 - XML-индексы

Таким образом, мы все еще можем наблюдать увеличение до 3198 (3199-1) в будущих версиях SQL Server.

Ранее я думал, что sys.indexes является синонимом sysindexes, но я обнаружил, что они отличаются, sysindexes имеет indid (вместо index_id) и не содержит строк для XMLиндексы!

index_id из sys.indexes имеет тип int (4 байта), а indid из sys.sysindexes имеет тип smallint (2 байта) (SQL Server 2008, вероятно, увеличен по сравнению с предыдущими версиями)

Я нашел полезным иИнтересная статья Тибор Караси.Подсчет ключей в sys [.] Indexes

2 голосов
/ 22 ноября 2010

Ну, для SQL Server 2005 и более ранних версий ..

  • 0 = куча.Каждая таблица содержит хотя бы одну запись в sys.indexes, даже если она не имеет индексов
  • 1 = кластеризованный
  • 255 = для SQL Server 2000 и более ранних версий для столбцов больших объектов (не могу вспомнить, почему сейчас)

То есть сразу у вас было максимум 253 индекса NC (от 2 до 254).

Округление?Или какая-то устаревшая причина SQL Server 7.0 / 6.5 / 6.0 / 4.2?

2 голосов
/ 22 ноября 2010

AFAIK - это просто произвольные ограничения, с которыми мало кто сталкивается на практике.Предположительно, им нужно установить какой-то максимальный лимит, чтобы они знали, сколько места нужно выделить в их внутренних структурах.Возможно, они просто решили, что decimal(3,0) будет достаточно для хранения indexid!

Если бы они допустили 1000 в SQL Server 2008, спросили бы вы, почему бы не 1001?

1 голос
/ 29 ноября 2010

Это в основном внутреннее ограничение реализации. Он не определяется размером метаданных (т. Е. Столбцом tinyint или небольшим столбцом int для index_id), но вместо этого является столбцом метаданных, который отражает внутреннее ограничение.

Всякий раз, когда появляется такое ограничение, это означает, что где-то в коде существуют практические ограничения того, как это обрабатывается. Чтобы привести пример, возможно, генерация плана запроса станет слишком сложной, если потребуется учесть десятки тысяч индексов в одной таблице и потребуется гораздо больше времени для создания даже тривиального плана. Столкнувшись с такими проблемами, проводится черта на то, что считается «разумным» числом. ~ 250 индексов казались разумными в конце 90-х, предел был доведен до 1000 в R2.

1 голос
/ 22 ноября 2010

Ранняя версия SQL Server использовала бы поле tinyint для идентификатора индекса.Максимальное значение Tinyint равно 255. Команда разработчиков, возможно, округлила его до 250, чтобы его было легко запомнить (как это было с ограничением в 8000 символов для полей varchar).250 индексов разделены: один кластеризованный индекс и 249 некластеризованных индексов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...