Кластеризованные индексы на неидентификационных столбцах для ускорения массовой вставки?
У меня два вопроса:
- Могу ли я использовать кластерные индексы для ускорения увеличивать объемные вставки в большие таблицы?
- Могу ли я по-прежнему эффективно использовать отношения внешнего ключа, если мои Столбец IDENTITY не кластеризован index?
Для уточнения, у меня есть база данных с парой очень больших (от 100 до 1000 миллионов строк) таблиц, содержащих данные компании. Обычно в такой таблице содержатся данные о 20-40 компаниях, каждая из которых представляет собой свой «кусок», отмеченный «CompanyIdentifier» (INT). Кроме того, в каждой компании около 20 отделов, каждый из которых имеет свой собственный «фрагмент», помеченный «DepartmentIdentifier» (INT).
Часто бывает, что целый «фрагмент» или «фрагмент» добавляется или удаляется из таблицы. Моя первая мысль заключалась в том, чтобы использовать разделение таблиц для этих кусков, но, поскольку я использую SQL Server 2008 Standard Edition, я не имею на это права. Тем не менее, большинство запросов, которые у меня есть, выполняются для «фрагмента» или «фрагмента», а не для таблицы в целом.
Я работал над оптимизацией этих таблиц для следующих функций:
- Запросы, выполняемые на подгруппах
- Запросы «Бенчмаркинг», которые выполняются для таблицы в целом
- Вставка / удаление больших фрагментов data.
По 1) и 2) я не столкнулся с большим количеством проблем. Я создал несколько индексов по ключевым полям (также содержащие CompanyIdentifier и DepartmentIdentifier, если это полезно), и запросы выполняются нормально.
Но для 3) я изо всех сил пытался найти хорошее решение. Я создал несколько индексов по ключевым полям (также содержащие CompanyIdentifier и DepartmentIdentifier, если это полезно), и запросы выполняются нормально.
Но для 3) я изо всех сил пытался найти хорошее решение. Я создал несколько индексов по ключевым полям (также содержащие CompanyIdentifier и DepartmentIdentifier, если это полезно), и запросы выполняются нормально.
Но для 3) я изо всех сил пытался найти хорошее решение. Моя первая стратегия заключалась в том, чтобы всегда отключать индексы, массово вставлять большой кусок и перестраивать индексы. Вначале это было очень быстро, но теперь, когда в базе данных много компаний, требуется очень много времени, чтобы каждый раз перестраивать индекс.
На данный момент моя стратегия изменилась и теперь я просто оставляю индекс включенным. при вставке, так как теперь это кажется быстрее. Но я хочу еще больше оптимизировать скорость вставки.
Кажется, я заметил, что добавление кластерного индекса, определенного в CompanyIdentifier + DepartmentIdentifier, ускоряет загрузку новых «фрагментов» в таблицу. Раньше я отказался от этой стратегии в пользу добавления кластерного индекса в столбец IDENTITY, поскольку в нескольких статьях мне указывалось, что кластеризованный индекс содержится во всех других индексах, и поэтому кластерный индекс должен быть как можно меньше. Но сейчас я думаю о возрождении этой старой стратегии для ускорения вставок. На мой вопрос, будет ли это разумным или у меня будут проблемы с производительностью в других областях? И действительно ли это ускорит мои вставки, или это всего лишь мое воображение?
Я также не уверен, действительно ли нужен столбец IDENTITY в моем случае. Я хотел бы иметь возможность устанавливать отношения внешнего ключа с другими таблицами, но могу ли я также использовать для этого что-то вроде схемы CompanyIdentifier + DepartmentIdentifier + [uniquifier]? Или это должен быть фрагментированный номер IDENTITY для всей таблицы?
Большое спасибо за любые предложения или объяснения.