¿Cómo consulto esta vista de registro de 20 millones más rápido?

14

Para una funcionalidad de búsqueda, estoy usando una vista que tiene los registros de todas las tablas dentro de las cuales necesito buscar. La vista tiene casi 20 millones de registros. Las búsquedas en contra de esta vista están tomando demasiado tiempo.

¿Dónde debo buscar para mejorar el rendimiento de esta vista?

La definición aproximada de la vista está abajo. Incluye trece mesas y alrededor de treinta campos.

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 balu
fuente

Respuestas:

9

Una vista es macro que se expande. Entonces, si su vista es una UNIÓN de 2 tablas, el plan de ejecución mostrará las 2 tablas. La vista es transparente.

Esto no se aplica si la vista está indexada / materializada. Sin embargo, entonces no harías esta pregunta.

Entonces, ¿qué dice el plan de ejecución? El DTA? ¿Falta índices de consulta dmv? ¿La consulta dmv más cara?

gbn
fuente
Él podría estar haciendo la pregunta de una vista materializada, y se da cuenta de que está implementado típicamente como otra mesa, por lo que puede ser indexado, etc.
Joe
@Joe: posiblemente, pero OP no estaría pidiendo ayuda si supieran las diferencias ...
gbn
La pregunta está etiquetada para MS SQL Server, por lo que en lugar de "vistas materializadas" deberíamos hablar de "vistas indexadas";)
AndrewSQL
1
@ AndrewSQL: lo hice. Pero deberíamos atender las formas de vida más bajas ...
gbn
6

Sin más detalles sobre la vista y las tablas, la respuesta es "depende", pero podría comenzar a buscar en la cláusula WHERE de su vista los campos que pueden requerir índices.

ggponti
fuente
1
Pero yo tenía la impresión de que las opiniones en general no se benefician en gran medida de índices (... según "Me dijeron que por este tipo que conozco")
jcolebrand
55
@jcolebrand: las vistas en general son muy útiles por los índices, dependiendo de cómo se usen. Esencialmente, cuando se usan en una consulta determinada, se beneficiarán como si su código se insertara directamente en la consulta. Para vistas simples + consultas, esto significa que usan índices tan bien como lo haría cualquier consulta simple. Para vistas / consultas más complejas, depende de qué tan bien el planificador de consultas pueda reorganizar y optimizar el trabajo a realizar. La mejor manera de ver esto es elegir un conjunto de datos grande y fabricar algunas vistas y consultas de ejemplo con ellas, y ver qué dice la pantalla del plan de consultas de SSMS que hace el QP con ellas.
David Spillett
6

Además de lo que otros han dicho (cláusula WHERE, ÍNDICES que podrían ayudar), sugiero que desee considerar las vistas indexadas, suponiendo que incluso sea posible crear índices en la vista ( detalles ). Entonces también puede aplicar la sugerencia NOEXPAND en sus consultas ( detalles ).

AndrewSQL
fuente
Estos detalles suenan prometedores. Permítanme probarlos y volveré sobre los resultados.
balu
4

La respuesta genérica es echar un vistazo al plan de ejecución. ¿Están indexadas sus uniones? ¿Están incluidos sus campos de salida en esos índices? ¿Solo está generando las columnas que necesita ver?

Matt M
fuente
0

Lo que probablemente haría, es crear 2 vistas

  • La primera vista es solo de los campos que necesito buscar; solo esos campos. Devolvería el campo de ID para cada fila, además de qué tipo de tabla está buscando. Hice algo similar al crear una vista UNION ALL que buscó en varias tablas. Solo me aseguré de incluir la identificación, el tipo y los campos de texto que quería buscar.

  • La segunda vista se encargaría de mostrar los resultados reunidos en la primera vista, y tendría todas las tablas que necesita para mostrar los resultados, o quizás en lugar de una vista, lo convierta en un procedimiento almacenado.

Haría UNION ALL, con GROUP BY en la parte inferior, y no haría todas esas UNIDADES EXTERIORES IZQUIERDAS.

crosenblum
fuente