Удаление первичного ключа (кластеризованного индекса) для повышения производительности вставки

Question

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

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

Выполнение select top 10 возвращает недавно вставленные записи, а не «первые» записи. order by работает, конечно, но я ожидаю, что вершина select должна возвращать строки в зависимости от их порядка на диске - что, я ожидаю, вернет самые низкие значения PK.

Было предложено удалить кластеризованный индекс, а также первичный ключ (ограничение уникальности). Как я упоминал ранее, нет необходимости select из этой таблицы в этой системе.

Какое влияние на производительность создает кластерный индекс для таблицы? Каковы (не выбранные) последствия наличия неиндексированной, некластеризованной таблицы без ключей? Любые другие предложения?

редактировать

наш аудит включает в себя функции CLR, и теперь я проверяю с использованием и без использования PK, индексов, FK и т. Д. Для определения относительной стоимости функций CLR и ограничений.

После расследования плохая производительность была связана не с заявлениями insert, а с функцией CLR, которая организовывала аудит. После удаления CLR и использования прямого процесса TSQL производительность повысилась в 20 раз.

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

// updating 10k rows in a table with trigger

// using CLR function
PK (identity, clustered)- ~78000ms
No PK, no index - ~81000ms

// using straight TSQL
PK (identity, clustered) - 2174ms
No PK, no index - 2102ms

Answer 1

По словам Кимберли Трипп - королевы индексации - наличие кластеризованного индекса в таблице действительно повышает производительность INSERT:

Продолжение дебатов по кластерному индексу

• Вставки в кластеризованной таблице выполняются быстрее (но только в «правильной» кластеризованной таблице) по сравнению с кучей.Основная проблема заключается в том, что поиск в IAM / PFS для определения местоположения вставки в куче выполняется медленнее, чем в кластеризованной таблице (где местоположение вставки известно, определяется кластерным ключом).Вставки выполняются быстрее, когда вставляются в таблицу, где порядок определен (CL) и где этот порядок постоянно увеличивается.

Источник: публикация в блоге под названием Дебаты о кластеризованных индексах продолжаются.... ** 1017

Answer 2

Отличный сценарий тестирования и описание этого сценария доступны в блоге Тибора Караси по адресу SQLblog.com

Мои числа не полностью совпадают с его числами - я вижу больше различий в пакетном операторе, чем я делаю для операторов на строку.

При количестве строк около одного миллиона я достаточно последовательно получаю однострочный цикл вставки в кластеризованном индексе, который работает немного быстрее, чем в неиндексированном (кластеризованный занимает примерно 97%, если не проиндексирован).

И наоборот, пакетная вставка (10000 строк) быстрее в неиндексированный, а не кластеризованный индекс (от 75% до 85% времени кластеризованной вставки).

clustered - loop        - 1689
heap      - loop        - 1713
clustered - one statement - 85
heap      - one statement - 62

Он описывает, что происходит на каждой вставке:

Куча: SQL Server нужно найти, куда должна идти строка. Для этого это использует одну или несколько страниц IAM для кучи, и это перекрестные ссылки на одну или несколько страниц PFS для файла (ов) базы данных. ИМО, там должно быть потенциальным для заметных накладных расходов здесь. И даже больше, со многими пользователи, забивающие одну и ту же таблицу, я могу представить себе блокировку (ожидание) против страницы PFS и, возможно, также IAM.

Кластерная таблица: Теперь это очень просто. SQL-сервер перемещается по Дерево кластеризованного индекса и найдите, куда должна идти строка. Так как это постоянно увеличивающийся индексный ключ, каждая строка будет идти до конца таблицы (связанный список).

Answer 3

Мое примитивное понимание состоит в том, что даже операции INSERT обычно быстрее с кластеризованным индексом, чем с кучей. Кроме того, требования к дисковому пространству ниже с кластерными индексами.

Некоторые интересные тесты / сценарии, которые могут пролить свет на ваши конкретные обстоятельства: http://technet.microsoft.com/en-us/library/cc917672.aspx.

Answer 4

Стол без ключа?Даже не автоинкрементный суррогатный ключ?: (

Пока ключ монотонно увеличивается , обслуживание индекса при вставке должно быть хорошим - оно просто "добавлено в конце". "Кластеризация" означает только физическую структурутаблицы следует за индексом (поскольку данные являются частью индекса). Пока индекс не фрагментирован (см. монотонно увеличивается бит), сам кластер / данные не будут логически фрагментированыи это не должно быть проблемой производительности. (Если есть обновления, кластеризация - это немного другая история: обновленная запись может «расти» и вызывать фрагментацию.)

Я предлагаю, если этозатем выберите выбранный маршрут ... сравните его с реалистичными данными / нагрузкой, а затем решите, оправданы ли такие предложения. Было бы приятно узнать, было ли принято решение об этом изменении и почему.

Удачное кодирование.

---

Кроме того, любая зависимость от заказа, за исключением того, что у ORDER BY, имеет недостатки в дизайне. Это может сработать сейчас, но это деталь реализации иd может меняться незаметно (так же просто, как другой план запроса).С ключом автоинкремента ORDER BY DESC всегда будет давать правильный результат (имейте в виду, что идентификаторы автоинкремента могут быть пропущены, но если «сбросить», они всегда будут увеличиваться в зависимости от порядка вставки).