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

Question

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

select distinct w.packageid, e.OrgPackageEmailId
from epnunitsettings u,
wippackages w,
epnuser2unit n,
EpnOrgPackageEmails e,
aspnet_users r,
epnorgsettings g,
epnpackages k 
where u.SendPackageEmail = 'true'
and w.unitid = u.unitid
and n.unitid = u.unitid
and e.unitid = u.unitid
and e.userid = r.userid
and e.disabled = 'false'
and g.orgid = e.orgid
and not exists (select 1 from WipPackageEmails
where packageid = w.packageid
and OrgPackageEmailId = e.orgpackageemailid)
and g.orgid in (3163,3261)
and g.SendPackageEmail = 'true'
and w.packageid = k.wippackageid
and k.status < 10000

Answer 1

Как и все, кто прокомментировал, лучше всего решить проблему с производительностью, если следующая информация предоставлена ​​как минимум:

1. Размер базовых таблиц
2. Подробности индекса в базовых таблицах
3. Скриншот плана выполнения

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

1. Пожалуйста, перепишите запрос, используя ANSI JOINS, и предоставьте Требуется фильтр объединений как можно раньше, чтобы помочь SQL Server руководство к лучшему плану, избегая ненужных строк столы как можно раньше.

2. Пожалуйста, убедитесь, что все столбцы, используемые для «поиска» и «сортировка» (объединенные столбцы, где условие и искомые столбцы, сгруппировать, упорядочить по, разным) в запросе приведены ключи некоторых полезных индекс, который может использоваться запросом. Я бы предложил создать составные некластерные индексы, которые имеют все необходимые ключи от таблица, чтобы покрыть объединения и поиски, сделанные в таблице, а чем создание отдельного некластеризованного индекса для каждого поля. Так как чем больше у вас некластеризованного индекса, тем больше переходов отдельные страницы данных SQL Server придется сделать, чтобы получить то, что он потребности, и это будет медленнее, чем найти все поля нужно вместе.

3. Помните, что SQL Server может использовать один индекс таблицы для присоединение к другой таблице (если не требуется поиск по ключу или RID) из некластеризованного индекса, чтобы найти другие необходимые столбцы, используемые в соединении / выборе / поиске в кластерном индексе). Следовательно, будь умным придумывая свою стратегию индекса относительно этого и сделать уверен, что у вас есть составной индекс, чтобы покрыть это. Только тогда вы бы быть в состоянии видеть «поиск индекса» в вашем плане выполнения, а не много много «индексных сканирований» и «поисков».

4. Пожалуйста, убедитесь, что ваши объединенные столбцы из разных таблиц одного и того же типа данных, чтобы избежать неявного преобразования, которое очень дорого. То же самое и с обычными поисками. Если это не так, вы можете пойти с некоторыми предложениями, представленными в моем комментарии здесь: Почему тег запроса "IN" стоит так дорого в хранимых процедурах sql?

5. Как объяснено в приведенной выше ссылке, если ваши объединенные типы данных не являются то же самое, тогда при использовании функции CONVERT () в вашем присоединении условия / поиски, чтобы избежать неявного преобразования, вы должны рассмотрите возможность создания индекса columnstore, а не индекса rowstore, чтобы убедиться что запрос может правильно использовать индекс для этого столбца.

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