Як швидше запитати цей перегляд запису на 20 мільйонів?


14

Для функції пошуку я використовую представлення, в якому є записи з усіх таблиць, в яких мені потрібно шукати. Перегляд має майже 20 мільйонів записів. Пошуки цього погляду забирають занадто багато часу.

Куди слід шукати, щоб покращити ефективність цієї точки зору?

Приблизне визначення для подання наведено нижче. Він включає тринадцять таблиць і близько тридцяти полів.

CREATE VIEW [dbo].[v_AllForSearch]
AS
SELECT 
  FT.firstField AS [firstField]
, FT.fld_primary AS [fld_primary]
, FT.fld_thirdField AS [thirdField]
, FT.fld_fourthField AS [fourthField]           
, ISNULL(ST.[fld_firstSearchField],'') AS [firstSearchField]
, ISNULL(TT.[fld_thirdSearch],'') AS thirdSearch
, ISNULL(TT.[fld_fourthSearch],'')AS fourthSearch
, ISNULL(TT.[fld_fifthSearch],'')AS fifthSearch
, ISNULL(FRT.[fld_sixthSearch],'') As [sixthSearch]
, ISNULL(FRT.[fld_seventhSearch],'') AS [seventhSearch]
, ISNULL(FRT.[fld_eightSearch],'')AS [eightSearch]
, ISNULL(FIT.[fld_nineSearch],'') AS [nineSearch]
, ISNULL(SIT.[fld_tenthSearch],'')AS [tenthSearch]
, ISNULL(SET.[fld_eleventhSearch],'') AS [eleventhSearch]
, ISNULL(ET.[twelthSearch],'')AS [twelthSearch]
, ISNULL(NT.[thirteenthSearch],'')AS [thirteenthSearch]
, ISNULL(NT.[fourteenSearch],'') AS [fourteenSearch]
, ISNULL(NT.[fifteenSearch],'') AS [fifteenSearch]
, ISNULL(NT.[sxteenSearch],'')  AS [sxteenSearch]
, ISNULL(NT.[seventeenSearch],'') AS [seventeenSearch]
, ISNULL(NT.[eighteenSearch],'')AS [eighteenSearch]
, ISNULL(TT.[ninteenSearch],'') AS [ninteenSearch]
, ISNULL(ELT.[twentySearch],'') AS [twentySearch]
, ISNULL(ELT.[twentyOneSearch],'') AS [twentyOneSearch]
, ISNULL(TWT.[twentyTwoSearch],'') AS [twentyTwoSearch]
, ISNULL(THT.twentyThree,'') AS [twentyThree]
, ISNULL(THT.twentyFour,'') AS [twentyFour]
, ISNULL(THT.twentyFive,'') AS [twentyFive]
, ISNULL(THT.twentySix,'') AS [twentySix]
FROM 
      tblFirstTable AS FT         
      LEFT JOIN [tblSecondTable] AS ST 
            ON ST.[fld_primary] = FT.[fld_primary]        
      LEFT JOIN [tblThirdTable] AS TT 
            ON TT.[fld_primary] = FT.[fld_primary]        
      LEFT JOIN [tblFourthTable] AS FRT 
            ON FRT.[fld_primary] = FT.[fld_primary]       
      LEFT JOIN [tblFifthTable] AS FIT 
            ON FIT.[fld_primary] = FT.[fld_primary]       
      LEFT JOIN [tblSixthTable] AS SIT 
            ON SIT.[fld_primary] = FT.[fld_primary]       
      LEFT JOIN [tblSeventhTable] AS SET 
            ON SET.[fld_primary] = FT.[fld_primary]       
      LEFT JOIN [tblEighthTable] AS ET 
            ON ET.[fld_primary] = FT.[fld_primary] 
      LEFT JOIN [tblNinthTable] AS NT 
            ON NT.[fld_primary] = FT.[fld_primary]        
      LEFT JOIN [tblELTnthTable] AS TT 
            ON TT.[fld_primary] = FT.[fld_primary]        
      LEFT JOIN [tblEleventhTable] AS ELT 
            ON ELT.[fld_primary] = FT.[fld_primary]       
      LEFT JOIN [tblTwelthTable] AS TWT 
                            ON TWT.[fld_id] = ELT.[fld_id]  
              LEFT JOIN [tblThirteenthTable] AS THT
            ON THT.[firstField]= FT.[firstField]
WHERE fld_Status ..

Відповіді:


9

Перегляд - це макрос, який розширюється. Отже, якщо ваш погляд є СПІЛЬНОЮ з 2 таблиць, план виконання покаже 2 таблиці. Вид прозорий.

Це не застосовується, якщо представлення індексовано / матеріалізовано. Однак тоді ви б не ставили цього питання.

Отже, що говорить план виконання? DTA? Відсутній індекс dmv-запиту? Найдорожчий dmv-запит?


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

@Joe: можливо, але тоді ОП не буде просити про допомогу, якби вони знали відмінності ...
gbn

Питання позначено для MS SQL Server, тому замість "матеріалізованих поглядів" ми повинні говорити про "індексовані погляди";)
AndrewSQL

1
@AndrewSQL: Я це зробив. Але ми повинні задовольнити нижчі форми життя ...
gbn

6

Без додаткових деталей про подання та таблиці відповідь "це залежить", але ви можете почати переглядати пункт WHERE для вашого поля для полів, які можуть вимагати індексів.


1
Але в мене склалося враження, що погляди взагалі не сильно виграють від індексів (... відповідно до "мені розповів цей хлопець, якого я знаю")
jcolebrand

5
@jcolebrand: переглядам загалом дуже допомагають індекси, залежно від способу їх використання. По суті, при використанні в заданому запиті вони матимуть користь, як якщо б їх код був вставлений безпосередньо в запит. Для простих переглядів + запитів це означає, що вони використовують індекси, а також будь-який простий запит. Для більш складних переглядів / запитів залежить, наскільки добре планувальник запитів може переставити і оптимізувати роботу, яку потрібно виконати. Найкращий спосіб переконатись у цьому - вибрати великий набір даних та виготовити деякі приклади представлень даних та запитів, використовуючи їх, і побачити, що на дисплеї плану запитів SSMS говорить QP з ними.
Девід Спіллетт

6

На додаток до того, що сказали інші (WHERE пункт, INDEXes, які можуть допомогти), я пропоную вам розглянути індексовані представлення - припускаючи, що навіть можливе створення індексів у поданні ( деталі ). Тоді ви можете також застосувати підказку NOEXPAND у своїх запитах ( деталі ).


Ці деталі звучать багатообіцяюче. Дозвольте спробувати ці результати і повернусь до результатів.
balu

4

Загальна відповідь полягає в тому, щоб подивитися план виконання. Ваші приєднання індексуються? Чи включаються ваші вихідні поля до цих індексів? Ви виводите лише стовпці, які вам потрібно побачити?


0

Можливо, я б просто створив 2 перегляди

  • 1-й вид - це лише ті поля, які мені потрібно шукати; просто ті поля. Я б повертав ідентифікаційне поле для кожного рядка, плюс таблицю, яку ви шукаєте. Я зробив подібну річ, створивши перегляд UNION ALL, який шукав декілька таблиць. Я щойно переконався, що включив ідентифікатор, тип та текстові поля, які я хотів шукати.

  • Другий вигляд оброблятиме відображення результатів, зібраних у 1-му поданні, і кожна таблиця, яка вам потрібна для відображення результатів, або, можливо, замість перегляду, зробить це збереженою процедурою.

Я б зробив об'єднання ВСЕ, з групою BY внизу, і я б не робив усіх цих лівих приєднань.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.