_>Объясните пожалуйста, в чем разница между ними.. _>И если можно какие нить ссылки по MS SQL
В Microsoft SQL Server индекс представляет собой B+tree, узлы которого состоят из ключевых полей, а в листьях (узлах самого последнего уровня) содержатся ссылки на записи таблицы.
Индекс может быть двух типов, кластерный (clustered) и не кластерный.
Кластерный индекс отличается от некластерного тем, что в листьях этого индекса содержатся не ссылки на записи в таблице, а сами записи. Таким образом, при наличии кластерного индекса записи в таблице выстраиваются в порядке ключей такого индекса (строго говоря это не совсем так, но в первом приближении верно). По очевидным причинам кластерный индекс может быть только один на таблицу. Идентификация конкретной записи в таблице также находится в прямой зависимости от наличия кластерного индекса. Если кластерного индекса нет, то запись находится по уникальному идентификатору записи – RID, который однозначно определяет ее положение в файле данных. Если же кластерный индекс в таблице присутствует, то физическое место этой записи не постоянно, а, следовательно, использовать RID не очень практично, поскольку его пришлось бы обновлять во всех индексах при каждом изменении. Поэтому запись идентифицируется по ключу кластерного индекса.
Здравствуйте, feanor_ka, Вы писали:
_>Объясните пожалуйста, в чем разница между ними..
_>И если можно какие нить ссылки по MS SQL
На самом деле все просто: если у таблицы есть кластерный индекс, то записи, находящиеся в этой таблице, физически (в дисковом файле) упорядочиваются в соответствии с условием индексирования). Именно поэтому кластерный индекс может быть на таблицу только один. Некластерный индекс хранит ссылки на местоположение данных в дисковом файле.
Со всеми вытекающими.
Вытекающие:
1. Скорость доступа к строкам, при указании условия where, совпадающиего с условием индексирования для кластерного индекса, будет выше, чем при поиске записей по простому индексу (не надо высислять абсолютное положение данных из относительного).
2. Если кластерный индекс содержит большое количество часто обновляемых полей, то это отрицательно скажется на производительности, так как приведет к постоянному физическому перупорядочиванию данных.
3. Если кластерный индекс создается по IDENTITY столбцу, и из таблицы часто удаляются записи, то это приводит к сильной фрагментации таблицы.
Здравствуйте, dingo, Вы писали:
D>На самом деле все просто: если у таблицы есть кластерный индекс, то записи, находящиеся в этой таблице, физически (в дисковом файле) упорядочиваются в соответствии с условием индексирования).
Упорядочиваются, но не физически — логически. В пределах одной страницы упорядочиваются физически.
Здравствуйте, dingo, Вы писали:
D>На самом деле все просто: если у таблицы есть кластерный индекс, то записи, находящиеся в этой таблице, физически (в дисковом файле) упорядочиваются в соответствии с условием индексирования).
Не верно, без ряда существенных оговорок.
D>1. Скорость доступа к строкам, при указании условия where, совпадающиего с условием индексирования для кластерного индекса, будет выше, чем при поиске записей по простому индексу <...>
Не совсем верно.
D>2. Если кластерный индекс содержит большое количество часто обновляемых полей, то это отрицательно скажется на производительности, так как приведет к постоянному физическому перупорядочиванию данных.
Не совсем верно.
D>3. Если кластерный индекс создается по IDENTITY столбцу, и из таблицы часто удаляются записи, то это приводит к сильной фрагментации таблицы.
Опять-таки не совсем верно...
Здравствуйте, andsm, Вы писали:
A> В пределах одной страницы упорядочиваются физически.
Даже в пределах одной страницы физически не упорядочиваются... "Уж сколь твердили миру..." http://rsdn.ru/Forum/Message.aspx?mid=731932&only=1
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, andsm, Вы писали:
A>> В пределах одной страницы упорядочиваются физически. M>Даже в пределах одной страницы физически не упорядочиваются... "Уж сколь твердили миру..." M>http://rsdn.ru/Forum/Message.aspx?mid=731932&only=1
M>Есть лишь гарантия того, что не придется "прыгать" за следующей записью из середины страницы, если на этой странице еще есть нужные записи.
Я, конечно, все понимаю, но нужно сопоставлять уровень ответа с уровнем вопроса. Давайте не будем пугать человека, делающего первые шаги, страшными словами.
Здравствуйте, dingo, Вы писали:
D>Я, конечно, все понимаю, но нужно сопоставлять уровень ответа с уровнем вопроса.
Угу, только при этом все равно следует давать точные ответы, а не приблизительные.
D> Давайте не будем пугать человека, делающего первые шаги, страшными словами.
Если что-то непонятно — человек делающий первые шаги в состоянии уточнить — не маленький, это гораздо лучше чем намеренно вводить его в заблуждение.
Здравствуйте, dingo, Вы писали:
D>Здравствуйте, Merle, Вы писали:
M>>Здравствуйте, andsm, Вы писали:
A>>> В пределах одной страницы упорядочиваются физически. M>>Даже в пределах одной страницы физически не упорядочиваются... "Уж сколь твердили миру..." M>>http://rsdn.ru/Forum/Message.aspx?mid=731932&only=1
M>>Есть лишь гарантия того, что не придется "прыгать" за следующей записью из середины страницы, если на этой странице еще есть нужные записи.
D>Я, конечно, все понимаю, но нужно сопоставлять уровень ответа с уровнем вопроса. Давайте не будем пугать человека, делающего первые шаги, страшными словами.
Пугайте-пугайте, я далеко не первые шаги делаю.. т.ч. чем точнее-тем лучше я буду только рад.. огромное спасибо!!!
Либо ссылки не те, либо одно из двух.
Мы уже победили, просто это еще не так заметно...
