|
![]() |
#1 |
Moderator
|
А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса. Поэтому при выборке по некластерному индексу, фактически делается две выборки: Сначала выбираются значения ключей кластерного индекса из обычного индекса, затем по значениям этих ключей, выбираются записи из кластерного индекса. Так что я вот к рекомендации BP отношусь достаточно настороженно; Кластерный индекс однозначно лучше только в том случае, если процентов 70 выборок делается ТОЛЬКО по нему, а все остальные индексы используются только в каких-то экстремальных случаях.
|
|
![]() |
#2 |
Злыдни
|
|
|
![]() |
#3 |
Moderator
|
Не совсем. В кластерном индексе тоже может быть несколько уровней у дерева. То есть - если у нас все индексы обычные, мы после сканирования получили список rowid и на доступ к каждой записи по rowid нам требуется ОДНО обращение к диску. В случае наличия кластерного индекса, если мы отсканировали обычный индекс, мы получили список ключей кластерного индекса. И потом для поиска каждой такой записи нам нужно минимум ДВА доступа к диску (вырожденный случай, когда у нас вся таблица влезла в одну страницу не рассматриваем). А если записей нас много - то и уровней в кластерном индексе может быть 3-4-5. Соответственно - поиск по обычному индексу занял 3 доступа к диску, а потом еще поиск по кластерному индексу занял 3 доступа к диску. Время поиска выросло почти в два раза...
|
|
![]() |
#4 |
Злыдни
|
|
|