Улучшить время выполнения отдельного запроса

Question

У меня проблемы с получением полного набора результатов для запроса ниже.Когда я выбираю отчетливый топ 10000, я получаю результаты в секундах.Когда я вынимаю это, оно продолжает работать больше 1 часа.Я проверил и попытался проиндексировать такие поля, как regnum company + country inc, но без разницы.Жаба предложила добавить следующий индекс:

USE [BW_DCF];
    GO
CREATE NONCLUSTERED INDEX [idx_Nonclustered_WeccoParty_OverallStatus]
ON [CORE].[WeccoParty]
([OverallStatus])
INCLUDE (
[GtId], [CrmPartyId], [FirstName], [LastName], [LegalName], [CountryInc], 
[BusinessClass], [RmFullName], [PbeFullName], [OverallClientStatus], 
[OverallRpStatus], [CompanyRegNum] 
)
WITH
(
PAD_INDEX = OFF,
FILLFACTOR = 100,
IGNORE_DUP_KEY = OFF,
STATISTICS_NORECOMPUTE = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON,
DATA_COMPRESSION = NONE
)
ON [BW_DCF_Group1];
GO



   select distinct wp1.GtId, 
  wp1.CrmPartyId, 
  wp1.LegalName, 
  wp1.BusinessClass, 
  wp1.RmFullName, 
  wp1.PbeFullName, 
  wp1.OverallClientStatus, 
  wp1.OverallRpStatus, 
  wp1.FirstName,
  wp1.LastName,  
  wp1.LegalName,
  wp1.CountryInc,
  wp1.CompanyRegNum,
  wp2.GtId, 
  wp2.CrmPartyId, 
  wp2.LegalName, 
  wp2.BusinessClass, 
  wp2.RmFullName, 
  wp2.PbeFullName, 
  wp2.OverallClientStatus, 
  wp2.OverallRpStatus,  
  wp2.FirstName,
  wp2.LastName,
  wp2.LegalName,
  wp2.CountryInc,
  wp2.CompanyRegNum
     from CORE.WeccoParty wp1
      join CORE.WeccoParty wp2 on   wp1.CompanyRegNum = wp2.CompanyRegNum
                    and wp1.CountryInc = wp2.CountryInc     
                    and wp1.GtId <> wp2.GtId 
                and wp1.OverallStatus = 'Onboarded'
            and wp2.OverallStatus = 'Onboarded'

Answer 1

Спасибо за добавление плана выполнения.Я могу дать вам только несколько советов.

1. Predicate GeneralStatus = 'Onboarded' - это тот, который выбирает данные для сравнения.Сколько строк он выбирает из общего количества строк в CORE.WeccoParty?Если оно меньше <5-10%, вы можете попытаться создать индекс для него.Вы также можете сначала создать временную таблицу с данными, отфильтрованными по этому предикату, а затем соединить их. </li>
2. Если в CORE требуется выбрать больше данных, чем 5-10%, лучше выполнитьполное сканирование этой таблицы для исключения выбора данных с использованием двух индексов и последующего объединения результатов с помощью операции хеширования.
3. Похоже, что соединение между данными, выбранными с помощью wp1 и wp2, выполняется с помощью операции слияния.Эта операция требует первой сортировки входных данных для wp1 и wp2, попробуйте устранить ее, добавив подсказку для хеш-соединения:

FROM CORE.WeccoParty wp1 INNER HASH JOIN CORE.WeccoParty wp2 на
wp1.CompanyRegNum = wp2.CompanyRegNum

или присоединение к вложенному циклу:

ОТ CORE.WeccoParty wp1 ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПЕТЛИ CORE.WeccoParty wp2 на
wp1.CompanyRegNum = wp2.CompanyRegNum

Вы также можете попробовать создать вспомогательный индекс и проверить производительность

CREATE INDEX IX_WeccoParty_1 ON CORE.WeccoParty (TotalStatus, CompanyRegNum, CountryInc, GtId)

Пытались ли вы обновить статистику в таблице CORE.WeccoParty.

Рассматривая план выполнения, могу поспорить, что это объединение слиянием может быть виновником и извлечением данных перед присоединением к данным.

Answer 2

Длинные времена запроса часто лежат на переполнении пространства ОЗУ или в базе данных, у которой недостаточно свободного пространства ОЗУ.Этот запрос является полностью нормальным, и в действительности повышение производительности невозможно.

В качестве решения я бы дал базе данных больше оперативной памяти для работы.

По своему опыту я увидел, что у sql-сервера возникают огромные проблемы, когда ему не хватает места в оперативной памяти.PostgreSQL, похоже, справляется с этим гораздо быстрее.