Повышение производительности запросов, добавление запросов к сеткам предложений до остановки - PullRequest
0 голосов
/ 31 октября 2019

Запуск следующего SQL приводит к запросу, который выполняется примерно за 0,338 с

, добавляя предложение where и время ожидания запроса. Все, чего я хочу добиться, - это список результатов теста для определенного test_code

Result_Set будет иметь много Test_Results для индекса Result_Set_Row_ID Date_Received_Index будет иметь много Result_Sets для индекса Result_Set_Row_ID

Я попытался изменитьпорядок соединений, добавление предложений к операторам соединения.

SELECT 
              Date_Received_Index.Registration_Number,
              Date_Received_Index.Specimen_Number,
              Result,
              Result_Comment,
              Result_Comment_Exp ,
              Result_Exp,
              Short_Exp,
              Test_Code,
              Test_Exp,
              Test_Row_ID,
              Units,
              Result_Set.Set_Code ,
              Result_Set.Date_Time_Authorised,
              Result_Set.Date_Booked_In ,
              Date_Received_Index.Discipline,
              Date_Received_Index.Namespace
FROM         
              Result_Set
              INNER JOIN Test_Result ON Result_Set.Result_Set_Row_ID = Test_Result.Result_Set_Row_ID
              INNER JOIN Date_Received_Index ON (Date_Received_Index.Request_Row_ID = Result_Set.Request_Row_ID)

WHERE         
              DATEDIFF('D', Date_Received_Index.Date_Received, current_timestamp) < 1 AND
              Date_Received_Index.Namespace = 'CHM' 

добавление предложения WHERE, например,

          DATEDIFF('D', Date_Received_Index.Date_Received, current_timestamp) < 1 AND
          Date_Received_Index.Namespace = 'CHM' 
     AND Test_Code = 'K'

приводит к истечению времени ожидания запроса

Я хотел быуметь создавать оператор SQL, который является производительным и просто выбирает код test_code, указанный в предложении where.

1 Ответ

0 голосов
/ 01 ноября 2019

Это сводится к плану запросов. Можете ли вы поделиться планом запроса? Я подозреваю, что столбец Test_Code не проиндексирован, и добавление к предложению WHERE заставляет оптимизатор выбрать неправильный план запроса.

Я думаю, что оптимизатор SQL не может оптимизировать часть DATEDIFF ('D', Date_Received_Index.Date_Received, current_timestamp) <1 </p>

, не зная вашей схемы, мой вопрос будет касаться трех столбцов, используемых в предложении where, Date_Received_Index.Date_Received, Date_Received_Index.Namespace и Test_Code являются любыми из этих столбцов индекса. Вы уже указали, что Test_Code не является.

В зависимости от того, какую версию Cache вы используете, вы можете попробовать

SELECT 
Date_Received_Index.Registration_Number,
Date_Received_Index.Specimen_Number,
Result,
Result_Comment,
Result_Comment_Exp ,
Result_Exp,
Short_Exp,
Test_Code,
Test_Exp,
Test_Row_ID,
Units,
Result_Set.Set_Code ,
Result_Set.Date_Time_Authorised,
Result_Set.Date_Booked_In ,
Date_Received_Index.Discipline,
Date_Received_Index.Namespace
FROM     %PARALLEL
Result_Set
INNER JOIN Test_Result ON Result_Set.Result_Set_Row_ID = Test_Result.Result_Set_Row_ID
INNER JOIN Date_Received_Index ON (Date_Received_Index.Request_Row_ID = Result_Set.Request_Row_ID)

WHERE         
DATEDIFF('D', Date_Received_Index.Date_Received, current_timestamp) < 1
AND Date_Received_Index.Namespace = 'CHM' 
AND Test_Code = 'K'

Использование% PARALLEL может привести к выполнению запроса с использованием нескольких потоков. Если сервер имеет большое количество процессоров, он может работать быстрее, даже если он не оптимизирован.

...