0

У меня есть следующий запрос в хранимой процедуре:Как улучшить Perfomance из запроса SQL Server

UPDATE dbo.CRM_tblActivityStore 
SET StoDateChngFlg = CASE 
      WHEN x.STAGE_STAD <> x.ACTSTR_STAD THEN 1 ELSE 0 END 
FROM (SELECT CASE 
WHEN sd.stad = '00000000' THEN '12-31-2049' ELSE CONVERT (DATE, sd.stad) 
END AS STAGE_STAD, 
       CONVERT (DATE, tas.StoDateSTA) AS ACTSTR_STAD, 
       tas.StoActivityNbr, 
       sd.Proj_Code, 
       sd.OrderNbr, 
       sd.FileNbr 
     FROM [SCM Server].[OrdrMgmt].dbo.STAGE_StageData AS sd 
       INNER JOIN 
       dbo.CRM_tblActivityStore AS tas 
       ON sd.Proj_Code = tas.StoProjCode 
        AND sd.OrderNbr = tas.StoOrderNbr 
        AND sd.FileNbr = tas.StoFile) AS x 
     INNER JOIN 
     dbo.CRM_tblActivityStore AS tast 
     ON tast.StoActivityNbr = x.StoActivityNbr 
      AND tast.StoProjCode = x.Proj_Code 
      AND tast.StoOrderNbr = x.OrderNbr 
      AND tast.StoFile = x.FileNbr; 

Некоторые больше информации, которая может помочь:

[SCM сервера] [OrdrMgmt] .dbo.STAGE_StageData. - имеет более 2 000 000 строк dbo.CRM_tblActivityStore - имеет более 5 000 000 строк

Ни одна из этих таблиц не проиндексирована и не имеет ключа Primery.

Это займет больше 3 часов.

Как можно улучшить добавление индекса?

Любые другие идеи, как улучшить его?

Спасибо,

Илан

+1

Yikes !!! Таблицы без кластеризованных индексов называются кучами. У вас есть пара хороших размеров. Здесь нет никаких шансов улучшить производительность без каких-либо структурных изменений в ваших таблицах. Вам нужен первичный ключ, и вам нужно будет добавить некоторую индексацию. Без подробностей трудно понять, что это может быть. –

+0

первая сделка - обновить статистику second - indexes – DimaSUN

+0

Я заметил, что вы используете таблицу со связанного сервера в соединении. Нехорошая идея (имхо). Если U использует SQL Server 2008+ - попробуйте использовать cross apply – DimaSUN

ответ

0

При оптимизации запросов я всегда начинаю с помощью

Включить фактический план выполнения

вариант в SSMS, по опции меню Query.

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

Удачи вам в этом. Я уверен, что вы можете свести этот запрос на несколько минут.

+1

почему голос? Не воссоздавая свою БД, будет сложно улучшить его запрос. Поэтому руководство его к надлежащим инструментам, безусловно, может помочь ему. – zukanta

+0

Я не вижу причины, чтобы проголосовать за это. Это единственный ответ, который помогает улучшить запрос сам, а не только индексы и ключ Primery, которые, как я знаю, у меня есть проблема. – user2743760

0

Ваша база данных будет значительно улучшена путем добавления некоторых индексов. В запросе, который вы указали, у вас есть несколько объединений, которые будут полезны при индексировании связанных столбцов. I.e. sd.Proj_Code = tas.StoProjCode и sd.OrderNbr = tas.StoOrderNbr и sd.FileNbr = tas.StoFile

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

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

1

Как говорит Дэвид, добавив, индексы объединения столбцы улучшат время отклика для этого запроса. Однако это не касается основной проблемы, почему эти таблицы не имеют первичных ключей. Первичный ключ уникально идентифицирует каждую строку в таблице. Вы/действительно/уверены, что ваша модель данных позволяет дублировать строки? Если да, уверены ли вы, что это соответствует потребностям вашего бизнеса? Есть ли другой, возможно, лучший способ приблизиться к проблеме, которую вы пытаетесь решить.

Правила для рассмотрения: 1 - каждая строка однозначно идентифицировать (первичный ключ) 2 - каждый столбец в строке связан с первичным ключом 3 - каждый столбец только первичный ключ

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

Смежные вопросы