Еще раз про кластерный индекс

Хм, почитал немного литературы, полазил на форумах, получил кучу противоречивой друг другу информации.

Значит есть таблица, имеющая около двух миллионов записей, в которую практически постоянно в течении нескольких часов в сутки автоматически добавляются записи (точнее происходит обновление информации по методу - старое удаляется и вся обновленная инфа пишется заново, количество записей после окончания обновления остается примерно одинаковым, тут еще надо сказать, что удаляется не вся база, а частями (то есть сначала delete from where, затем тыщу раз там insert values() и опять по кругу, меняются только условия для удаления записей)). Таблица заполняется единственной(!!!) программой (то есть практически писать в базу больше одного клиента никто никогда не будет). Но чтение из базы выполняется и выполняется и часто и много и несколькими клиентами практически одновременно. Происходят выборки по полю charrec типа varchar(255), имеется некластерный не уникальный индекс по этому полю. Естественно имеется поле numrec типа int identity.

Так вот я так считаю, что мне либо кластерный индекс нафиг тут не нужен (как сейчас) либо его все-таки нужно создать, но вполне логично сделать по полю numrec (что во многих книгах да и практически везде на форуме не приветствуется из-за блокировки страниц) для того, чтобы уменьшить количество страниц, занимаемых таблицей и соответственно уменьшить время выборки по полю charrec.

Хочу узнать мнения профи, потому что рисковать создавать кластерные индексы по каждому полю и смотреть что из этого выйдет у меня к сожалению возможности нет. Подскажите пожалуйста!!!

знаешь у меня была подобная проблема некоторое время назад, но в основе моих изысканий было подобрать такие индексы которые значительно ускорили бы поиск, поскольку при имеющихся объёмах(Таблицу каждые сутки заносится до полумиллиона записей) искалось всё долго. Выборки делаются по различным полям многие из которых те же nvarchar, короче я сделала один кластерный индекс, содержащий все поля по которым часто осуществляются выборки ... и знаешь это сработало , время отклика значительлно уменьшилось.

Возможен у Вас вариант: одна база для удаления и вставки(индексов нет вообще), другая для чтения на нее уже рассмотреть создание индексов(Tuning wizard), а обновления делать с помощью транзакционной репликации в те часы когда изменение и чтений нет или в меньшем количестве ночью.

кластерный индекс - запись быстрее чем некластерный
покрывающий кластерный индекс даст прирост при выборках

чтобы избежать ожидания запросов на выборку на блокировке пока формируются новые данные -
завести две таблицы. все процедуры многократной перезаписи в процессе подготовки данных вести в одной табличке а когда они сформированы в транзакции удалить и залить в рабочую подготовленные данные целиком.

1. delete from where. Если вот в этом where получается последовательный наборо строк, например where Data between @a and @b, то по этому столбцу Data лучше сделать кластерный индекс - удаление будет идти быстрее.
Если типа delete from where id in (select id from) - то лучше некластерный, и вообще отказаться от кластерного индекса на таблице.
2. Всесто тысячи одичных вставок, лучше все вставить в отдельную таблицу и в одной транзакции переписать все в основную.

Насчет двух таблиц - одной для записи, второй для выборки.
Этот вариант я уже рассматривал - он немного для меня не подходит. Не буду объяснять почему - это долго. Да и алгоритм придется переделывать - на это времени у меня тоже нету.

Насчет создания кластерного индекса по всем полям - все равно самое главное поле, по которому идет "сортировка" - левое в индексе. Так что смысле в таком подходе я тоже не вижу. Интересно было бы узнать, какое поле в вашем случае самое левое - identity или содержащее данные.

И все-таки хотелось узнать в конкретном приведенном мною случае - нужны кластерные индексы или нет и если нужны, то как правильно их сделать в моем случае.

В BOL есть рекомендации относительно кластерного индекса, их желательно создавать, в случаях, если:
Из таблицы производятся выборки по диапазону, например по диапазону дат или номеров
Запросы возвращают объемные результаты
Таблицы используются в JOIN операциях (в этом случае желательно наличие кластерного индекса на том поле, на котором опрелены внешние ключи)
Используется сортировка или агрегирование результатов запросов

В вашем случае, если чтение производится только одного поля, то достаточно (IMHO) индекса на этом поле. Добавление любого индекса приведет к потерям на иго перестройку при записи и удалении данных.

...

Удаление и вставка в таблицу, в которой создан кластерный индекс выполняется намного дольше. Ведь при удалении и вставке системе приходиться физически перемещать кучу данных кроме тех, которые добавляете (удаляете)
Если важна скорость для выборки, то кластерный индекс нужен, если важно скорость добавления данных, то - нет

Andrey_Lar

Удаление и вставка в таблицу, в которой создан кластерный индекс выполняется намного дольше. Ведь при удалении и вставке системе приходиться физически перемещать кучу данных кроме тех, которые добавляете (удаляете)

Добавление - если меняются индексированные столбцы и если страница заполнена