Мы столкнулись с тайм-аутами SQL и определили, что узким местом является таблица аудита — все таблицы в нашей системе содержат триггеры вставки, обновления и удаления, которые вызывают новую запись аудита.
Это означает, что таблица аудита является самой большой и загруженной таблицей в системе. Тем не менее, данные только входят и никогда не выходят (в этой системе), поэтому select производительность не требуется.
Запуск select top 10 возвращает недавно вставленные записи, а не «первые» записи. order by работает, конечно, но я ожидаю, что select top должен возвращать строки в зависимости от их порядка на диске, что, как я ожидаю, вернет самые низкие значения 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
