iscrafmну и?? Что нового сказали?Он, в общем-то, ссылку на статью кинул.
Но если своими словами говорить о сути кластерного индекса, то получается:
- на "железном уровне" - это и есть сама таблица, и отделить его на уровне файловых групп от данных не получится. Хорошо дефрагментированный кластерный индекс обеспечивает быстрый поиск по нему.
А для того, чтобы кластерный индекс не слишком быстро фрагментировался, его размер должен быть не более 8 байт, например, одно поле типа datetime(как в приведённом примере), либо два типа integer
Во многих таблицах 1С, как я понял, я сам туда не заглядывал (поверим на слово автору совета) - в качестве первичного ключа используется GUID, вот только не знаю, кластерный он в регистрах, или некластерный - по той же причине (не заглядывал в 1С).
Причём это не имеет смысла в обоих случаях, и особенно плохо, в случае кластерного:
1) Его размер - больше 8 байт (быстро фрагментируется, что приводит к резкому падению производительности).
2) В сиквеле до 2005 бессмыслен предикат order by по этому полю.
В случае же, если строить часто обновляемую таблицу на куче, новые записи кладутся в беспорядке, что также приводит к падению производительности при поиске.
На самом деле существует очень много споров о том, строить таблицы на куче либо на основе кластерного индекса.
По моим личным наблюдениям получается, что кластерный индекс (нормального размера, разумеется) выгоден, если запись таблицы полностью физически помещается в страницу данных (8192 байта).
Типы данных, наиболее подходящие для кластерного индекса:
datetime (как предложено в примере)
int либо (int+int)
bigint.
Причём, если в таблице нет (либо нет необходимости) в поле типа datetime, то лучше прибегать к целочисленному типу данных, причём если не ожидается более 4 миллиардов записей, то лучше использовать int (разумеется, используя отрицательную часть).
Хотя, из-за использования суррогатных ключей (в данном случае монотонно возхрастающим/убывающим - int identity), тоже бывают жаркие религиозные споры (в данном случае я-за ).
Некластерные же индексы можно выносить в другую файловую группу.
Покрывающим индексом в запросе чаще бывает именно некластерный (за исключением запросов типа select * from mytable ...), и его нахождение в другой файловой группе также увеличивает производительность (за счёт распараллеливания процессов чтения).
Вообще про индексы можно много и долго рассказывать, но если коротко и своими словами (как комментарий к примеру) - примерно так.