Проблема производительности с запросом SQL Server в хранимой процедуре

Question

Мы столкнулись с проблемой производительности хранимой процедуры, вызываемой из приложения .net (служба Windows) с использованием корпоративной библиотеки Microsoft 3.0.Процедура SQL Server просто проверяет существование записи и, если она не существует, вставляет запись в таблицу, в противном случае она просто возвращает их.

В таблице имеются следующие столбцы:

create table AlarmLog 
(
    Id                   bigint
    MessageId            int
    MessageTime          datetime
    ControllerId         int
    InterfaceHardwareId  int
    IDType               int
    MapId                int
    RelatedEmployeeId    int
    RelatedCardId        int
);

Столбец Id является первичным ключом и имеет кластеризованный индекс.

Как бизнес-правило, при вставке записи в нее мы должны убедиться, что комбинация (MessageId, MessageTime, ControllerId, InterfaceHardwareId, IDType, MapId) является уникальной.Следовательно, мы ставим условие if exists, чтобы проверить, существует ли уже комбинация.Эта проверка состояния занимает много времени.

Мы попытались добавить некластеризованный индекс для MessageId, MessageTime, ControllerId, InterfaceHardwareId, IDType, MapId.

На тестовом сервере в нашей лаборатории имеется около 30 000 000 записей, и даже если условие выполняется, оно вставляет довольно быстро, примерно 400+ строк в минуту, используя тот же сервис .net.Мы также попытались добавить вышеупомянутый некластеризованный индекс и обнаружили некоторое заметное улучшение.

• Версия SQL Server: стандарт SQL Server 2008
• .NET Framework 4.0
• ОС: Windows Server 2012 R2 Standard

На рабочем сервере существует более 300 000 записей, и когда мы вставляем строку за строкой из приложения .net (служба Windows) с выполненным условием,он вставляет только от 10 до 20 строк в минуту.Если мы удалим проверку условия, то количество вставленных строк увеличится до 300-400+ строк в минуту.Мы также попытались добавить / удалить вышеупомянутый некластеризованный индекс, но не нашли заметного улучшения.

Следовательно, мы пока держим его отключенным.Интересно, что если мы запустим хранимую процедуру из SQL Server Management Studio для вставки 1 записи, это не проблема, мы также проверили фактический план выполнения, не происходит сканирование таблицы и хранимая процедура не занимает какое-то время.

• Версия SQL Server: SQL Server 2012 Standard SP3
• .NET Framework 4.0
• ОС: Windows Server 2012 R2 Standard

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

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

Заранее спасибо.Ujjal

Answer 1

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

Answer 2

Добавить уникальное ограничение , а не индекс, как в:

alter table AlarmLog add constraint uq_alarmlog_row unique (
  MessageId, MessageTime, ControllerId, 
  InterfaceHardwareId, IDType, MapId);

Это автоматически отклонит вставку новой строки, значения которой точно соответствуют этой комбинации столбцов.

Это также должно быть быстрым с точки зрения производительности.Нет необходимости вызывать процедуру для запуска предыдущего select и проверки существования значений.

Просто запустите простой SQL insert и проблема решена.