SQL быстрые вставки без обновлений

Question

Мы используем одну таблицу для аудита в БД SQL Server 2008.

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

Но это главное узкое место для всей БД. Все ВСТАВКИ и ОБНОВЛЕНИЯ должны проходить таблицу аудита.

Мы уже используем NOLOCK HINT для операторов SELECT.

Поскольку в этой таблице нет ОБНОВЛЕНИЙ, есть ли предложения по улучшению пропускной способности операторов INSERT?

Answer 1

Убедитесь, что у вас есть первичный кластеризованный индекс INT (или BIGINT) IDENTITY в таблице! И желательно никаких других индексов (если это возможно) - это замедлит вставки.

Распространено заблуждение, что поскольку для таблицы нужны только ВСТАВКИ и почти нет чтения, вам следует «избавить» себя от проблемы первичного кластерного ключа.

Как объясняет богиня индексации SQL Server Кимберли Трипп в своем превосходном сообщении в блоге Дебаты по кластерным индексам продолжаются :

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

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

Также, если ваша таблица только получает вставки и не обновляет / удаляет, вы должны обязательно использовать 100% FILLFACTOR для кластеризованного индекса, чтобы полностью заполнить эти страницы сервера SQL.

Марк

Answer 2

Единственные рекомендации, которые я бы сделал:

• убедитесь, что вы записываете как можно больше нестроковых значений
• инкапсулирует ваши записи в аудит с помощью хранимых процедур
• получить любые другие данные из вызовов хранимых процедур или
• рассмотрите возможность использования отдельного представления «только для этой цели» в своем контрольном выпуске. Убедитесь, что его соединения как можно меньше. Это представление будет использоваться для поиска PK для сообщений аудита и т. Д. При попытке найти FK для ваших строковых данных.
• не рекомендация, а факт: меньшее количество индексов означает более быструю вставку + более медленный выбор.
• рассмотрите возможность архивирования «старых» строк аудита в другую таблицу. Держите таблицу аудита как можно меньше. Переместите эти старые строки аудита в другую таблицу. Для создания отчетов / запросов создайте представление, которое будет join или union для «живых» и «старых» аудитов.

Answer 3

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