Почему Select Query замедляется при использовании целочисленного столбца в предложении select - PullRequest
Новая
       0

Почему Select Query замедляется при использовании целочисленного столбца в предложении select

2 голосов
/ 30 июля 2010

Я пытаюсь оптимизировать приведенный ниже запрос в SQL Server 2000. Каждая таблица содержит более 300 000 строк, кроме таблицы Prod_Lot_Stage_Wise_Detl, которая содержит 2 миллиона записей.

Когда я выполняю запрос ниже, без включения поля LotStgWs.Finished_Pcs (которое принадлежит таблице Prod_Lot_Stage_Wise_Detl), результат приходит в течение 20 секунд.В поле LotStgWs.Finished_Pcs время выполнения превышает 2 минуты.Я не понимаю, что здесь происходит и как SQL Server 2000 работает с целочисленными полями.Индексы определены правильно для каждой таблицы. 

SELECT 
 JangRecv.Jangad_Ref_Code,         
 LotRecv.Total_Pcs Org_Pcs,      
 LotRecv.Total_Cts Org_Cts,
 LotStgWs.Finished_Pcs,
        (Isnull(ReEst.Exp_Wt,LotRecv.Exp_Yield)) Exp_Yield
 FROM 
 Prod_Jangad_Receive_Tran  JangRecv With(NoLock) Inner Join 
 Prod_Lot_receive_Tran   LotRecv  With(NoLock) On      (JangRecv.Jangad_Seq_No = LotRecv.Jangad_Seq_No) Inner Join
 Prod_Lot_Stage_Wise_Detl  LotStgWs With(NoLock) On (
          LotStgWs.Jangad_Seq_No = LotRecv.Jangad_Seq_No  And 
          LotStgWs.Lot_Seq_No = LotRecv.Lot_Seq_No   And
          LotStgWs.Stage_Seq_No  = ISNULL(
                     (SELECT  MAX(Delv_Stage_Seq_No) 
               FROM  Prod_Lot_Delivery_Tran      
               WHERE  Jangad_Seq_No = JangRecv.Jangad_Seq_No
               ), JangRecv.Exp_Delv_Stage_Seq_No
              )
             ) Left Outer Join
 PPCS_QMA_Diamond_RE_Estimation  ReEst    With(NoLock) On (LotStgWs.Jangad_Seq_No = ReEst.Jangad_Seq_No And LotStgWs.Lot_Seq_No = ReEst.Lot_Seq_No And LotStgWs.Stage_Seq_No = ReEst.Stage_Seq_No)
Where 
 LotRecv.Lot_Recv_Div_Seq_No = 1
ORDER BY  JangRecv.Jangad_Ref_Code, LotRecv.Lot_Num_Alias

Ответы [ 3 ]

0 голосов
/ 30 июля 2010

Если я правильно понимаю проблему, то единственное, что вы изменяете в запросе, - это выбор LotStgWs.Finished_Pcs ... Если это так, у меня ранее была подобная проблема в SQL Server 2000 ... индекс на LotStgWs.Finished_Pcs. Это работало для меня раньше. Кажется, это не имеет большого смысла, но это работает. Желаем удачи

0 голосов
/ 30 июля 2010

Вы также можете попытаться перестроить индексы: http://www.sql -server-performance.com / tips / rebuilding_indexes_p1.aspx .

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

0 голосов
/ 30 июля 2010

Убедитесь, что у вас есть индексы для всего, к чему вы присоединяетесь, особенно для этой большой таблицы.Разница нетривиальна: поиск (или объединение) по неиндексированному столбцу требует полного сканирования таблицы, которое имеет линейную сложность (т. Е. Для двух миллионов записей необходимо выполнить два миллиона сравнений в худшем случае).В индексированном столбце ядро ​​базы данных может использовать двоичный поиск, который имеет логарифмическую сложность (т. Е. Для двух миллионов записей требуется 21 сравнение в худшем случае).

...