|
|
|
|
#1 |
|
Злыдни
|
|
|
|
|
|
#2 |
|
Moderator
|
Не совсем. В кластерном индексе тоже может быть несколько уровней у дерева. То есть - если у нас все индексы обычные, мы после сканирования получили список rowid и на доступ к каждой записи по rowid нам требуется ОДНО обращение к диску. В случае наличия кластерного индекса, если мы отсканировали обычный индекс, мы получили список ключей кластерного индекса. И потом для поиска каждой такой записи нам нужно минимум ДВА доступа к диску (вырожденный случай, когда у нас вся таблица влезла в одну страницу не рассматриваем). А если записей нас много - то и уровней в кластерном индексе может быть 3-4-5. Соответственно - поиск по обычному индексу занял 3 доступа к диску, а потом еще поиск по кластерному индексу занял 3 доступа к диску. Время поиска выросло почти в два раза...
|
|
|
|
|
#3 |
|
Злыдни
|
|
|
|
|
|
#4 |
|
SAP
|
Шутка с долей правды
"Кластерный индекс по recId был сделан для того что бы кто-нибудь не создал кластерный индекс по другому индексу ".
|
|
|
|
|
#5 |
|
SAP
|
Цитата:
В 4 врое как RecId выделяется на таблицу без учета компании. Или я что-то путаю ?
Но при этом всплыла интересная штука: "Нет гарантии, что записи, вставляемые в одну и ту же таблицу, будут иметь последовательные идентификаторы, если они вставляются различными серверами AOS" - во как. Так что, возможно кластерный индекс и зря предусмотрен для этой таблицы
|
|
|