Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 DBCC DBREINDEX  [new]
macros
Member

Откуда: Ural
Сообщений: 189
Посоветуйте как лучше сделать:

В БД есть очень большая таблица (примерно 10Гб)
на ней несколько индексов. после того как я удалил из нее примерно 15-25% записей (устаревших)
хотелось бы как то оптимизировать индексы и уменьшить размер файла БД

Начитавшись теории пришел к выводу что наилучшая последовательность действий такая:
1. Удалить ненужные записии
2. удалить все индексы
3. сжать БД
4. заново создать все индексы с опцией WITH SORT_IN_TEMPDB ()

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

Насколько верен мой подход?
и еще тут одна фигня - я могу пересоздать все индексы кроме кластеризованного. При попытке его удаления мне выдаеться сообщение:
An explicit DROP INDEX is not allowed on index Название Таблицы.названиеИндекса It is being used for PRIMARY KEY constraint enforcement

то есть его нельзя просто так пересоздать? кроме как командой DBCC DBREINDEX ?

Принимаю любые советы :)


Незнание - порождает стремление...
2 сен 09, 10:40    [7606739]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
а что, просто дбреиндекс использовать отказались? зачем обязательно удалять?

для спящего время бодрствования равносильно сну
2 сен 09, 10:57    [7606869]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
Gmur
Member

Откуда:
Сообщений: 16
Кластерный удалять не надо, он прекрасно перестраивается обычным ребилдом.
2 сен 09, 11:02    [7606923]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
1) Избавтесь от привычки создавать кластерный праймари кей.
2) Перед тем, как что перестраивать - лучше проверить дефрагментированность.Может вам и реорганайза хватит.
2 сен 09, 11:17    [7607016]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
mike909
Member

Откуда:
Сообщений: 662
macros
Посоветуйте как лучше сделать:

В БД есть очень большая таблица (примерно 10Гб)
Это не очень большая таблица ж-)
macros

на ней несколько индексов. после того как я удалил из нее примерно 15-25% записей (устаревших)
хотелось бы как то оптимизировать индексы и уменьшить размер файла БД

Начитавшись теории пришел к выводу что наилучшая последовательность действий такая:
1. Удалить ненужные записии
2. удалить все индексы
3. сжать БД
4. заново создать все индексы с опцией WITH SORT_IN_TEMPDB ()

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

1) Какой у Вас SQL ? Если SQL2k5 и удаление идет по условию Field[datetime] <= 'указаной дате',
То рассмотрите возможность перехода на секционированную таблицу. Тогда процесс удаления устаревших данных займет считаные наносекунды
2) А зачем удаять то ?
3) Полезное дело - можно довериться AutoShrink_у, но лучше руками.
4) Простой ребилд. В случае секционирования, можно еще и по секциям см. BOL

macros

и еще тут одна фигня - я могу пересоздать все индексы кроме кластеризованного. При попытке его удаления мне выдаеться сообщение:
An explicit DROP INDEX is not allowed on index Название Таблицы.названиеИндекса It is being used for PRIMARY KEY constraint enforcement

то есть его нельзя просто так пересоздать? кроме как командой DBCC DBREINDEX ?


Можно, грохнув PRIMARY KEY constraint, но сильно сомневаюсь что это Вам нужно.
И уж точно - неправильно, если он используется.
2 сен 09, 11:22    [7607053]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
macros
Member

Откуда: Ural
Сообщений: 189
mike909,

1. SQL2000 sp4 \ windows 2003sp2, удаление идет именно таким способом. про секционирование спасибо - почитаю конечно, но мне нужно избавиться именно от большого размера файла
2. удаляю чтоб потом создать уже на новом отфрагментированном месте (после shrink)
3. даю сжимать собираюсь вручную
4. простой ребилд будет использовать место в файле самой БД, тем самым увеличив время создания индекса

и вопрос к --__Александр__--
1. что значит избавиться от привычки прамери кей? разве это плохо?
2. дефрагментированность проверил - она пока еще не совсем запущена (для кластерного вообще все ок)

а перестроить и удалить некоторые хочу именно чтоб:
1. избавиться от фрагментации логический и физической
2. освободить место от ненужных индексов
2 сен 09, 12:39    [7607605]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
macros
Member

Откуда: Ural
Сообщений: 189
--__Александр__--
1) Избавтесь от привычки создавать кластерный праймари кей.
2) Перед тем, как что перестраивать - лучше проверить дефрагментированность.Может вам и реорганайза хватит.


еще раз внимательно прочитал ваше сообщение))
то есть, есть разница между перестройкой индекса и реорганайза? тогда что такое последнее?
2 сен 09, 13:12    [7607831]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
Crimean
Member

Откуда:
Сообщений: 13148
для SQL 2000 читаем / применяем DBCC DBREINDEX и щасте
P.S.
с ФФ не играемся, пусь будет такой, как есть по умолчанию
2 сен 09, 13:17    [7607885]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
erererererу1
Guest
сжимать не надо - от этого только дефрагментация повышается - все равно рано или поздно до этого же размера вырастет. ты просто ребилд сделай индексов - удалишь дефрагментацию и статистику за одно обновишь
2 сен 09, 13:27    [7607974]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
macros
Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.

Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
2 сен 09, 14:06    [7608237]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
ChA
Member

Откуда: Москва
Сообщений: 10989
--__Александр__--

Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.

Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
Просто феноменальные выводы. Это плод собственных размышлений или где-то вычитали ? Хотелось бы понять, что послужило причиной для столь громких утверждений.
2 сен 09, 15:42    [7608977]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
macros
Member

Откуда: Ural
Сообщений: 189
ChA
--__Александр__--

Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.

Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
Просто феноменальные выводы. Это плод собственных размышлений или где-то вычитали ? Хотелось бы понять, что послужило причиной для столь громких утверждений.


Вот именно. я тут уже столько всего прочитал.
И хотелось бы уже точно знать полезны\нужны ли эти кластерные индексы по ключевым полям. и если да то для каких таблиц, для больших или маленьких?

Может опросник создать? ))
2 сен 09, 15:44    [7608999]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
ChA
--__Александр__--

Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.

Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
Просто феноменальные выводы. Это плод собственных размышлений или где-то вычитали ? Хотелось бы понять, что послужило причиной для столь громких утверждений.


Достаточно рассмотреть таблицу вида
(Contract_ID,Contract_Date,Contract_SUM,....... )
Представим, что эта таблица кредитных договоров в Банке.
Причем Contract_ID не identity, а скажем символьное поле.

Contract_ID - primary key.Вы создаете кластерный индекс по Contract_ID.
Я говорю, что для этой таблицы кластерный индекс нужен на поле Contract_Date.

Теперь поразмыслите над следующими операциями, которые наиболее типичны для такой таблицы
1) Вставка в таблицу нового договора.
2) Выборка договоров за последний месяц.

Приведу еще один пример таблицы, где кластерный индекс вреден -
Таблицы, в которых происходит хаотичное(именно по primary key) вставка/удаление.
Причем нагруженность таблицы > 100 операций в секунду.

Остальные примеры расписывать лень,подумайте сами.
2 сен 09, 16:41    [7609358]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
macros
ChA
--__Александр__--

Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.

Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
Просто феноменальные выводы. Это плод собственных размышлений или где-то вычитали ? Хотелось бы понять, что послужило причиной для столь громких утверждений.


Вот именно. я тут уже столько всего прочитал.
И хотелось бы уже точно знать полезны\нужны ли эти кластерные индексы по ключевым полям. и если да то для каких таблиц, для больших или маленьких?

Может опросник создать? ))


Надо просто думать, как будет использоваться таблица и как на это будет влиять кластерный индекс по тому или иному полю. Книжки читать хорошо, но намного лучше уметь применять то, что вы вычитали.
2 сен 09, 16:44    [7609380]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
iljy
Member

Откуда:
Сообщений: 8711
--__Александр__--,

все, что вы говорите - относится к так называемым естественным ключам. И их действительно для кластерных индексов надо использовать осторожно. Но для этого существуют суррогатные ключи - те же identity. Так что вы не путайте теплое с мягким!
2 сен 09, 16:48    [7609406]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
iljy
Судя по-всему, вам очень нравится это вырожение. Интересно, что же с чем я перепутал?

Вы считаете что identity ключ - лучший вариант для кластерного индекса?
Сочувствую . . . .
1) Высоконагруженные таблицы в OLTP средах ввобще лучше работают без кластерных индексов.
(Где происходит хаотичная вставка удаление)
2) Любая таблица, в котрой порядок identity не совпадает с порядком по полю с датой, и для которой наиболее часто встречающиеся запросы - выборка за интервал по этой дате.

Опять же, можно написать еще примеры, но не все сразу.
2 сен 09, 16:57    [7609450]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
iljy
Member

Откуда:
Сообщений: 8711
Не надо передергивать мои слова. Я не сказал, что идентити надо использовать всегда.

2) Любая таблица, в котрой порядок identity не совпадает с порядком по полю с датой, и для которой наиболее часто встречающиеся запросы - выборка за интервал по этой дате.

Это как раз случай, когда лучше всего подходит естественный ключ.

--__Александр__--
iljy
1) Высоконагруженные таблицы в OLTP средах ввобще лучше работают без кластерных индексов.
(Где происходит хаотичная вставка удаление)


хаотичное УДАЛЕНИЕ - пожалуй единственная ситуация, в которой кластерный индекс мешает. Да и то - удаление записей может повлечь за собой перераспределение страниц, а это в свою очередь - изменение ВСЕХ некластерных индексов из-за изменения физического адреса записей (не удаленной, а остающихся в таблице). Так что даже тут не все так очевидно. Зачастую просто периодическое перестроение суррогатного кластера может вполне себе работать.
2 сен 09, 17:36    [7609720]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
iljy

Это как раз случай, когда лучше всего подходит естественный ключ.

Коллега, вы не улавливаете сути. Порядок в естесвенном ключе то же может не совпадать с порядком, по наиболее популярному полю.

iljy

хаотичное УДАЛЕНИЕ - пожалуй единственная ситуация, в которой кластерный индекс мешает.

А как же хаотичная вставка? А что если дерево перестраивать придется?
А сравните просто накладные расходы на поддержание этого кластерного индекса.
Причем на поддержание индекса, который не нужен. Без него и вставка работает быстрее и удаление.

iljy

Зачастую просто периодическое перестроение суррогатного кластера может вполне себе работать.

Правильнее в таких случаях просто создавать кластерный индекс, а потом его убивать.


Коллега, вы видимо верите в догму - "Любая таблица должна иметь кластерный индекс".
Оказывается, что это не так. Всегда нужно думать, что для таблицы будет лучше, какие индексы ускорят ее работу, какие замедлят.
2 сен 09, 17:48    [7609825]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
забавно наблюдать.
каждый говорит одно и тоже, но своими словами и пытается доказать что он правее.
вчитайтесь..

для спящего время бодрствования равносильно сну
2 сен 09, 18:06    [7609947]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
iljy
Member

Откуда:
Сообщений: 8711
--__Александр__--
iljy

Это как раз случай, когда лучше всего подходит естественный ключ.

Коллега, вы не улавливаете сути. Порядок в естесвенном ключе то же может не совпадать с порядком, по наиболее популярному полю.

Имеется ввиду, что данные вставляются не в порядке даты, а ищуться в основном по ней?
Индекс по наиболее популярному полю все равно создавать придется. И тут существуют ситуации, когда выгоднее создать кластер по этому полю, наплевав на порядок вставки, и поддерживать фрагментацию в приемлемых границах, чем мучится с перекрывающими индексами и т.д.
Фактически суррогатный кластер может использоваться как неменяющаяся физическая ссылка на строку. И тут накладные расходы на поддержание кластера могут быть сравнимы с расходами на изменение индексов при физическом перемещении страниц. Ну и опять же - размер ID может быть меньше размера RID ==> меньше размер индекса==> больше записей на страницу индекса, но это уже лирика


iljy

хаотичное УДАЛЕНИЕ - пожалуй единственная ситуация, в которой кластерный индекс мешает.

А как же хаотичная вставка? А что если дерево перестраивать придется?
А сравните просто накладные расходы на поддержание этого кластерного индекса.
Причем на поддержание индекса, который не нужен. Без него и вставка работает быстрее и удаление.

А что вставка? Для суррогатного ключа данные вставляются в порядке возрастания, хаотично вы их вставляете или нет

iljy

Зачастую просто периодическое перестроение суррогатного кластера может вполне себе работать.

Правильнее в таких случаях просто создавать кластерный индекс, а потом его убивать.

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





Коллега, вы видимо верите в догму - "Любая таблица должна иметь кластерный индекс".
Оказывается, что это не так. Всегда нужно думать, что для таблицы будет лучше, какие индексы ускорят ее работу, какие замедлят.

да нет, в догмы я не верю вообще. Просто хочу сказать, что ситуации, когда кластер вреден - очень редки и специфичны. И естественно, что если производительность при создании кластера падает - значит от него надо отказываться. Просто надо четко представлять себе, какие тут плюсы и минусы, а заодно какие возможны компромиссные решения.
2 сен 09, 18:10    [7609981]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
iljy
Member

Откуда:
Сообщений: 8711
Алексей2003,

Увы, такое часто бывает
2 сен 09, 18:11    [7609986]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
"да нет, в догмы я не верю вообще. Просто хочу сказать, что ситуации, когда кластер вреден - очень редки и специфичны. И естественно, что если производительность при создании кластера падает - значит от него надо отказываться. Просто надо четко представлять себе, какие тут плюсы и минусы, а заодно какие возможны компромиссные решения."

Так спор начался не из-за этого утверждения. Спор начался из-за того, что я сказал примерно следуюшее -
"Очень часто бывает, что primary key - не самый лучший кандидат на кластерный индекс.
И создавать кластерный primary key по умолчанию - ошибка. Надо сначала поискать более подходящего кандидата."
2 сен 09, 18:20    [7610043]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
iljy
Member

Откуда:
Сообщений: 8711
--__Александр__--,

ну я включился в спор после этого утверждения:

Достаточно рассмотреть таблицу вида
(Contract_ID,Contract_Date,Contract_SUM,....... )
Представим, что эта таблица кредитных договоров в Банке.
Причем Contract_ID не identity, а скажем символьное поле.

Contract_ID - primary key.Вы создаете кластерный индекс по Contract_ID.
Я говорю, что для этой таблицы кластерный индекс нужен на поле Contract_Date.

Теперь поразмыслите над следующими операциями, которые наиболее типичны для такой таблицы
1) Вставка в таблицу нового договора.
2) Выборка договоров за последний месяц.

Приведу еще один пример таблицы, где кластерный индекс вреден -

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

я увидел, и оборот "ЕЩЕ ОДИН ПРИМЕР" воспринял так, что первый пример был тоже на вредность кластера. А фразу
Я говорю, что для этой таблицы кластерный индекс нужен на поле Contract_Date.
как-то в середине текста пропустил
2 сен 09, 18:33    [7610093]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
ChA
Member

Откуда: Москва
Сообщений: 10989
--__Александр__--
Достаточно рассмотреть таблицу вида
(Contract_ID,Contract_Date,Contract_SUM,....... )
Представим, что эта таблица кредитных договоров в Банке.
Причем Contract_ID не identity, а скажем символьное поле.

Contract_ID - primary key.Вы создаете кластерный индекс по Contract_ID.
Я говорю, что для этой таблицы кластерный индекс нужен на поле Contract_Date.
Теперь поразмыслите над следующими операциями, которые наиболее типичны для такой таблицы
1) Вставка в таблицу нового договора.
2) Выборка договоров за последний месяц.
И к каким выводам нужно придти ?
--__Александр__--
Приведу еще один пример таблицы, где кластерный индекс вреден -
Таблицы, в которых происходит хаотичное(именно по primary key) вставка/удаление.
Причем нагруженность таблицы > 100 операций в секунду.
И в чём вред ? А мне известно, что для высоконагруженных таблиц специально делают "разноску" по кластерному индексу, дабы избегать hot spots и увеличить параллельность вставок.
--__Александр__--
подумайте сами.
Так давно, даже с экспериментами, еще до того, как Вы только начали разбираться с индексами. На эту тему в этом форуме полным-полно топиков, которые Вы явно не читали. Потому и удивился категоричности Ваших утверждений.

По пунктам.
--__Александр__--
Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка.
То есть вы джойнитесь по условию >= или в WHERE написан between.
В общем случае - строить кластерный индес по ключу является ошибкой.
Что значит "упорядочная выборка" ? Какие бы индексы не были построены, порядок вывода гарантируется только пунктом ORDER BY.
И почему вдруг "по условию >= или в WHERE написан between" ? Т.е., условие по равенству и кластерный индекс понятия несовместимые ? По первому же примеру получается, что смысл в кластерном индексе отсутствует, если мы хотим просмотреть договора за отдельные дни.
Взаимосвязь между кластеризацией и ключом вообще непонятна. Это как между "горячим" и "синим". Одно есть физическое понятие, другое логическое и находятся в разных измерениях.

--__Александр__--
Во-первых, нужно точно понять, нужен ли вам кластерный индекс на таблицу.
Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
Если нам нужны частые bookmark loop, то, действительно, зачем он нам ? Хотя по моим выводам, "хороший" кластерный индекс может дать возможность отказаться от части ненужных индексов, а в некоторых случаях и совсем.
Насчёт вредности всё-таки хотелось бы уточнений. Если это про
--__Александр__--
Таблицы, в которых происходит хаотичное(именно по primary key) вставка/удаление. Причем нагруженность таблицы > 100 операций в секунду.
, так опять-таки непонятна связь между "горячим" и "синим". PRIMARY KEY не является синонимом для кластерный индекс и наоборот. Но даже если они будут по одному и тому набору атрибутов, то поделитесь, пожалуйста, своим опытом, что же такое катастрофическое произойдёт в случае "нагруженных" систем ?
2 сен 09, 19:15    [7610265]     Ответить | Цитировать Сообщить модератору
 Re: DBCC DBREINDEX  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
ChA
1)И к каким выводам нужно придти ?
К таким, что эта таблица на этих запросах будет быстрее работать с кластерным индексом по по полю
Contract_Date, нежели с индексом по полю Contract_ID.Для такого типа таблиц плохо создавать кластерный primary key.

2) "И в чём вред ? А мне известно, что для высоконагруженных таблиц специально делают "разноску" по кластерному индексу, дабы избегать hot spots и увеличить параллельность вставок."(а удалений?)
Вред в накладных расходах на поддержание индекса, который не нужен.А если на таблице помимо кластерного индекса еще индексы.Сами посчитайте, во что обойдется удаление/вставка из середины кластерного индекса.

3)"Что значит "упорядочная выборка" ? Какие бы индексы не были построены, порядок вывода гарантируется только пунктом ORDER BY.
И почему вдруг "по условию >= или в WHERE написан between" ? Т.е., условие по равенству и кластерный индекс понятия несовместимые ? По первому же примеру получается, что смысл в кластерном индексе отсутствует, если мы хотим просмотреть договора за отдельные дни."

Упорядочная выборка означает то, что выбираются данные за период и если по-этому полю есть кластерный индекс,то оптимизатор просматривает меньшее кол-во страниц, нежели если кластерного индекса не было.
Нет, условие = то же вполне подходит, просто на условиях >= выигрыш на много больше.

4)"Взаимосвязь между кластеризацией и ключом вообще непонятна. Это как между "горячим" и "синим". Одно есть физическое понятие, другое логическое и находятся в разных измерениях."
А взаимосвязь в том, что я против создания кластерного ключа по умолчанию, как сделал ТС.
Возможно для этой таблицы либо вообще не нужен кластерный индекс, либо есть более лучший кандидат.

5)"Если нам нужны частые bookmark loop, то, действительно, зачем он нам ? Хотя по моим выводам, "хороший" кластерный индекс может дать возможность отказаться от части ненужных индексов, а в некоторых случаях и совсем."
Что бы этого избежать есть покрывающие индексы и опция include.Если мы в запросах не получаем выигрыш от сортировки по кластерному индексу, то возможно для этой таблицы достаточно обычных,так как они априори короче кластерного.

6)"так опять-таки непонятна связь между "горячим" и "синим". PRIMARY KEY не является синонимом для кластерный индекс и наоборот."
Отвечаю еще раз. Я воюю против создания кластерного PRIMARY KEY, так как возможно для таблицы есть более лучший кандидат или кластерный индекс вообще не нужен.

7)"что же такое катастрофическое произойдёт в случае "нагруженных" систем ?"
При наличии на таблице большого числа индексов - сильно возрастают накладные расходы на вставку/удаление.

9)"На эту тему в этом форуме полным-полно топиков, которые Вы явно не читали. Потому и удивился категоричности Ваших утверждений."
Во-первых, вы ошибаетесь.Я очень много читаю. А во-вторых мои утверждения нельзя назвать категоричными,особенно - второе и третье.
По-моему, в моих утверждениях нет ничего категоричного.
-Кластерный индекс необходим по тем полям, по которым происходит упорядочная выборка?
-В общем случае - строить кластерный индекс по ключу является ошибкой.
-Кластерный индекс нужен не на каждую таблицу, а для определенных - он да же вреден.
3 сен 09, 08:03    [7611150]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить