Как быстрее запросить этот 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 ..
sql-server index optimization view Балу
источник

Ответы:

9

Представление - это макрос, который расширяется. Таким образом, если ваше представление является объединением 2 таблиц, план выполнения покажет 2 таблицы. Вид прозрачен.

Это не применяется, если представление проиндексировано / материализовано. Однако тогда вы бы не задавали этот вопрос.

Итак, что говорит план выполнения? ДТА? Отсутствуют индексы DMV-запроса? Самый дорогой запрос DMV?

ГБН
источник
Возможно, он задает вопрос о материализованном представлении и не понимает, что оно обычно реализуется как просто другая таблица, поэтому может быть проиндексировано и т. Д.
Джо,
@Joe: возможно, но тогда OP не попросил бы помощи, если бы они знали различия ...
gbn
Вопрос помечен для MS SQL Server, поэтому вместо «материализованных представлений» следует говорить об «индексированных представлениях»;)
AndrewSQL,
1
@AndrewSQL: я сделал. Но мы должны заботиться о низших формах жизни ...
gbn
6

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

ggponti
источник
1
Но у меня сложилось впечатление, что представления в целом не сильно выигрывают от индексов (... согласно «мне сказал этот парень, которого я знаю»)
jcolebrand
5
@jcolebrand: представлениям в целом очень помогают индексы, в зависимости от того, как они используются. По сути, при использовании в данном запросе они получат выгоду, как если бы их код был вставлен непосредственно в запрос. Для простых представлений + запросов это означает, что они используют индексы так же, как и любой простой запрос. Для более сложных представлений / запросов это зависит от того, насколько хорошо планировщик запросов может перестроить и оптимизировать работу, которую необходимо выполнить. Лучший способ убедиться в этом - выбрать большой набор данных и создать несколько примеров представлений и запросов, используя их, и посмотреть, что на экране плана запросов SSMS говорит QP.
Дэвид Спиллетт
6

В дополнение к тому, что сказали другие (предложение WHERE, INDEX, которые могут помочь), я предлагаю вам, возможно, захотеть рассмотреть индексированные представления - при условии, что даже возможно создать индексы для представления ( подробности ). Тогда вы также сможете применить подсказку NOEXPAND в ваших запросах ( подробности ).

AndrewSQL
источник
Эти детали звучат многообещающе. Позвольте мне попробовать их и вернемся к результатам.
Балу
4

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

Мэтт М
источник
0

Что я, вероятно, сделал бы, это просто создать 2 представления

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

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

Я бы сделал UNION ALL, с GROUP BY внизу, и я бы не сделал все эти ЛЕВЫЕ НАРУЖНЫЕ СОЕДИНЕНИЯ.

crosenblum
источник