SQL быстрые INSERT без UPDATE

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

Это распространенное заблуждение в том, что, поскольку таблице нужны только INSERT и вряд ли кто-либо читает, вы должны «сохранить» себе проблему с основным кластеризованным ключом.

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

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

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

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

Марк

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

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

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