Мне нужна помощь в ускорении времени выполнения моего сохраненного процесса

Question

Я хочу задать небольшой вопрос. Как я могу ускорить выполнение следующего сохраненного файла proc.First, нужно сказать, что в следующей таблице 30 000 000 строк:

CREATE TABLE tblT
  ( 
   [RowID] [int] IDENTITY(1, 1)
                 NOT NULL
  ,[CheckDateID] int NOT NULL
  ,[SSN] varchar(10)
  ,[CheckDate] datetime
  ,[val] money
    CONSTRAINT [PK_tblT]
    PRIMARY KEY CLUSTERED ( [CheckDateID] ASC, [RowID] ASC )
  )

И вот мы здесь, это SP, и мне нужны некоторые разумные советы о том, как я смогу изменить этот процесс. Критическим здесь является время выполнения процесса ...

DECLARE @RowMin [int]
 ,@RowMax [int]
 ,@Portion [int]
 ,@CurMin [int]
 ,@CurMax [int]
 ,@strMessage varchar(100)


SET @RowMin = ( SELECT min (RowID) FROM tblT )
SET @RowMax = ( SELECT max (RowID) FROM tblT )
SET @Portion = 350000
SET @CurMin = @RowMin
SET @CurMax = @CurMin + @Portion

WHILE @CurMax <> @CurMin
BEGIN

    Update A
    set val = val*8,3, --???
    from tblT  A 
    where A.RowID Between  @CurMin and @CurMax

    SET @CurMin = @CurMax
    SET @CurMax = case WHEN ( @CurMax + @Portion ) < @RowMax
                    THEN @CurMax + @Portion
                    ELSE @RowMax
                  END

END

Answer 1

Некоторые мысли:

• Есть ли индекс для RowID?

• Почему бы не сделать

  SELECT @ RowMin = min (RowID), @ RowMax = max (RowId) ОТ tbLT

вместо двух отдельных запросов

• Почему бы не просто

  update tbLT SET val = val * 8.3 ГДЕ rowID МЕЖДУ @CurMin и @ CurMax

• И самый большой вопрос, почему вы разбиваете заявление об обновлении? Это Мне кажется, вы пытаетесь сделать

update tbLT SET val = val * 8.3

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

Answer 2

Кроме того, что сказал Спарки - почему вы решили поставить ПК на (CheckDateId,RowID) ?? Любая конкретная причина?

Сделав это, вы фактически сделали этот индекс непригодным для запросов (например, вашего оператора UPDATE), которые ссылаются только на RowID -> вместо этого вы получите полное сканирование таблицы.

Три варианта:

1. Положите свой ПК на (RowID) один
2. Измените свой PK на (RowID, CheckDateID) - да, заказ имеет значение в этом случае!
3. Добавить новый некластеризованный индекс только для (RowID)

Все три параметра предназначены для ускорения запроса диапазона для RowID, который есть в вашем операторе UPDATE.

Однако имейте в виду, что настройка структуры базы данных для ускорения этого одного запроса может иметь побочные эффекты для остальной части вашей системы и других ваших запросов, и вы можете потенциально замедлить их. Подстройка только одного запроса / хранимого процесса в отдельности всегда очень опасная операция - вы можете нанести большой ущерб остальной системе.