Создание представления, производительность SQL-запросов

Question

Я пытаюсь создать представление, но выбор оператора из этого представления занимает более 15 секунд. Как я могу сделать это быстрее. Мой запрос на просмотр ниже.

create view Summary as

select distinct A.Process_date,A.SN,A.New,A.Processing,

COUNT(case when B.type='Sold' and A.status='Processing' then 1 end) as Sold,

COUNT(case when B.type='Repaired' and A.status='Processing' then 1 end) as Repaired,

COUNT(case when B.type='Returned' and A.status='Processing' then 1 end) as Returned

 from

 (select distinct M.Process_date,M.SN,max(P.enter_date) as enter_date,M.status,

 COUNT(case when M.status='New' then 1 end) as New,

COUNT(case when M.status='Processing' and P.cn is null then 1 end) as Processing

from DB1.dbo.Item_details M 

left outer join DB2.dbo.track_data P on M.SN=P.SN

group by M.Process_date,M.SN,M.status) A 

left outer join DB2.dbo.track_data B on A.SN=B.SN 

where A.enter_date=B.enter_date or A.enter_date is null 

group by A.Process_date,A.New,A.Processing,A.SN

После этого просмотра мой выбранный запрос

select distinct process_date,sum(New),sum(Processing),sum(sold),sum(repaired),sum(returned) from Summary where month(process_date)=03 and year(process_date)=2011

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

Спасибо ARB

Answer 1

Для настройки запроса к базе данных я добавлю несколько элементов в дополнение к тому, что @Davyd уже перечислил:

1. Посмотрите на таблицы и индексацию по этим таблицам.Установка правильного индекса и избежание неправильного всегда ускоряет запрос.
2. Есть ли что-то в условии where, которое не является частью какого-либо индекса?Иногда мы помещаем индекс в столбец, а в запросе используем приведение или преобразование столбца.Таким образом, базовый индекс не эффективен.Вы можете установить индекс на приведение / преобразование столбца.
3. Посмотрите на нормальное соответствие формы или чрезмерную нормализацию.3.

Удачи.

Answer 2

Трудно давать советы, не видя фактических данных и структуры таблиц. Я бы переписал запрос с учетом этих принципов:

1. Если возможно, используйте внутреннее соединение вместо внешнего соединения.
2. Избавьтесь от оператора case в функции COUNT. Создайте запрос, чтобы использовать условия в разделе WHERE, а не в COUNT.
3. Старайтесь не использовать агрегированные значения в GROUP BY. В настоящее время вы используете агрегированные значения New и Processing для группировки. Если возможно, используйте GROUP BY по существующим табличным значениям.
4. Если запрос становится слишком сложным, разбейте его на более мелкие запросы и объедините результаты в конечном запросе. В этом случае может помочь написание процедуры хранения.

Надеюсь, это поможет.

Answer 3

Если вы используете Postgresql, я предлагаю вам использовать инструмент типа "http://explain.depesz.com/", чтобы более четко увидеть, какая часть вашего запроса медленная. В зависимости от того, что вы получаете, вы можете либо оптимизировать свои индексы, либо переписать частьвашего запроса. Если вы используете другую базу данных, я уверен, что подобный инструмент существует.

Если ни одна из этих идей не поможет, окончательным решением будет создание «материализованного запроса». Существует множествоинформация об этом в Интернете.

Удачи.