我如何更快地查询这2000万条记录视图?


14

对于搜索功能,我正在使用一个视图,该视图具有需要搜索的所有表中的记录。该视图有近2000万条记录。针对该视图的搜索花费了太多时间。

我应该在哪里寻求改善这种观点的表现?

该视图的大致定义如下。它包括十三张桌子和大约三十个字段。

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 ..

Answers:


9

视图是扩展的宏。因此,如果您的视图是2个表的JOIN,则执行计划将显示2个表。视图是透明的。

如果视图已建立索引/实例化,则此方法不适用。但是,您不会问这个问题。

那么,执行计划怎么说?DTA?缺少索引dmv查询?最昂贵的dmv​​查询?


他可能会问一个物化视图的问题,并没有意识到它通常只是另一个表来实现,因此可以被索引,等等

@Joe:可能,但是如果他们知道差异,OP就不会寻求帮助...
gbn

这个问题是为MS SQL Server标记的,因此,我们应该谈论的不是“物化视图”,而是“索引视图”;)
AndrewSQL 2011年

1
@AndrewSQL:我做到了。但是我们应该迎合低等生活形式……
gbn

6

没有关于视图和表的更多详细信息,答案是“取决于”,但是您可以开始在视图的WHERE子句中查找可能需要索引的字段。


1
但是我给人的印象是,总体而言,视图并不能从索引中获得很大的收益(……据“我认识的那个人告诉我”)
jcolebrand

5
@jcolebrand:索引通常对视图有很大帮助,这取决于它们的使用方式。本质上,当在给定查询中使用它们时,它们将像直接将其代码插入查询一样受益。对于简单的视图+查询,这意味着它们与任何简单查询一样都使用索引。对于更复杂的视图/查询,这取决于查询计划程序可以重新安排和优化要完成的工作的程度。最好的查看方法是选择一个大型数据集并使用它们制作一些示例视图和查询,并查看SSMS的查询计划显示内容表明QP会对它们进行处理。
David Spillett

6

除了其他人所说的(WHERE子句,可能对INDEX有用)之外,我建议您考虑考虑索引视图-假设甚至有可能在视图上创建索引(详细信息)。然后,您也可以在查询中应用NOEXPAND提示(详细信息)。


这些细节听起来很有希望,让我尝试一下,然后再返回结果。
balu

4

通用答案是查看执行计划。您的联接是否被索引?这些索引中是否包含您的输出字段?您仅输出需要查看的列吗?


0

我可能要做的就是创建2个视图

  • 第一个视图只是我需要搜索的字段;只是那些领域。我将返回每一行的ID字段,以及您要搜索的表类型。通过创建搜索多个表的UNION ALL视图,我做了类似的事情。我只是确定要包括ID,类型和文本字段,以进行搜索。

  • 第二个视图将处理显示在第一个视图中收集的结果,并使每个表都需要显示结果,或者使它成为视图(而不是视图),使其成为存储过程。

我会做一个UNION ALL,底部是GROUP BY,而我不会做所有那些LEFT OUTER JOIN。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.