WEB开发网      婵犵數濮烽弫鍛婄箾閳ь剚绻涙担鍐叉搐绾剧懓鈹戦悩瀹犲闁汇倗鍋撻妵鍕箛閸洘顎嶉梺绋款儑閸犳劙濡甸崟顖氬唨闁靛ě浣插亾閹烘鈷掗柛鏇ㄥ亜椤忣參鏌″畝瀣暠閾伙絽銆掑鐓庣仭缁楁垿姊绘担绛嬪殭婵﹫绠撻、姘愁樄婵犫偓娴g硶鏀介柣妯款嚋瀹搞儱螖閻樺弶鍟炵紒鍌氱Ч瀹曟粏顦寸痪鎯с偢瀵爼宕煎☉妯侯瀳缂備焦顨嗗畝鎼佸蓟閻旈鏆嬮柣妤€鐗嗗▓妤呮⒑鐠団€虫灀闁哄懐濮撮悾鐤亹閹烘繃鏅濋梺闈涚墕濡瑩顢欒箛鏃傜瘈闁汇垽娼ф禒锕傛煕閵娿儳鍩f鐐村姍楠炴﹢顢欓懖鈺嬬幢闂備浇顫夊畷妯肩矓椤旇¥浜归柟鐑樻尭娴滃綊姊虹紒妯虹仸闁挎洍鏅涜灋闁告洦鍨遍埛鎴︽煙閼测晛浠滃┑鈥炽偢閹鈽夐幒鎾寸彇缂備緡鍠栭鍛搭敇閸忕厧绶炴俊顖滅帛濞呭洭姊绘担鐟邦嚋缂佽鍊垮缁樼節閸ャ劍娅囬梺绋挎湰缁嬫捇宕㈤悽鍛婄厽閹兼番鍨婚埊鏇㈡煥濮樿埖鐓熼煫鍥ュ劤缁嬭崵绱掔紒妯肩畺缂佺粯绻堝畷姗€濡歌缁辨繈姊绘担绛嬪殐闁搞劋鍗冲畷顖炲级閹寸姵娈鹃梺缁樻⒒閳峰牓寮崒鐐寸厱闁抽敮鍋撻柡鍛懅濡叉劕螣鐞涒剝鏂€闂佺粯鍔曞Ο濠囧吹閻斿皝鏀芥い鏃囨閸斻倝鎽堕悙鐑樼厱闁哄洢鍔屾晶顖炴煕濞嗗繒绠婚柡灞界Ч瀹曨偊宕熼鈧▍锝囩磽娴f彃浜炬繝銏f硾椤戝洨绮绘ィ鍐╃厵閻庢稒岣跨粻姗€鏌ㄥ☉妯夹fい銊e劦閹瑩顢旈崟顓濈礄闂備浇顕栭崰鏍礊婵犲倻鏆﹂柟顖炲亰濡茶鈹戦埄鍐ㄧ祷妞ゎ厾鍏樺璇测槈閵忕姈鈺呮煏婢跺牆鍔撮柛鏂款槺缁辨挻鎷呯粙搴撳亾閸濄儳鐭撶憸鐗堝笒閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓 ---闂傚倸鍊搁崐鐑芥倿閿旈敮鍋撶粭娑樺幘濞差亜鐓涢柛娑卞幘椤斿棝姊虹捄銊ユ珢闁瑰嚖鎷�
开发学院数据库MSSQL Server 用SQL Server 2005索引视图提高性能一 阅读

用SQL Server 2005索引视图提高性能一

 2007-05-31 15:22:50 来源:WEB开发网 闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷闂傚倸鍊搁崐椋庣矆娓氣偓楠炲鏁撻悩鎻掔€梺姹囧灩閻忔艾鐣烽弻銉︾厵闁规鍠栭。濂告煕鎼达紕校闁靛洤瀚伴獮鎺楀箣濠靛啫浜鹃柣銏⑶圭壕濠氭煙閻愵剚鐏辨俊鎻掔墛缁绘盯宕卞Δ鍐冣剝绻涘畝濠佺敖缂佽鲸鎹囧畷鎺戭潩閹典焦鐎搁梻浣烘嚀閸ゆ牠骞忛敓锟�婵犵數濮烽弫鍛婃叏椤撱垹绠柛鎰靛枛瀹告繃銇勯幘瀵哥畼闁硅娲熷缁樼瑹閳ь剙岣胯鐓ら柕鍫濇偪濞差亜惟闁宠桨鑳堕崝锕€顪冮妶鍡楃瑐闁煎啿鐖奸崺濠囧即閵忥紕鍘梺鎼炲劗閺呮稒绂掕缁辨帗娼忛埡浣锋闂佽桨鐒﹂幑鍥极閹剧粯鏅搁柨鐕傛嫹闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷  闂傚倸鍊搁崐鐑芥嚄閼哥數浠氱紓鍌欒兌缁垶銆冮崨鏉戠厺鐎广儱顦崡鎶芥煏韫囨洖校闁诲寒鍓熷铏圭磼濡搫顫嶅銈嗗姉閸樠囧煡婢跺á鐔兼煥鐎n兘鍋撴繝姘拺鐟滅増甯掓禍浼存煕閹惧鈽夐柍缁樻煥椤繈鎳滅喊妯诲闂備礁鎲$粙鎴︺偑閺夋垟鏋旈柡鍐e亾缂佺粯绋撴禒锕傚磼濮橆剦鐎抽梻浣哥-缁垶骞戦崶顒傚祦閻庯綆浜栭弨浠嬫煙闁箑澧い鏂垮€规穱濠囨倷椤忓嫧鍋撻弽褜娼栧┑鐘宠壘閸屻劎鎲歌箛娑樼疅闁圭虎鍠楅弲鎼佹煥閻曞倹瀚�
核心提示:一、索引视图 多年以来,MicrosoftSQL Server一直支持创建称为视图的虚拟表,用SQL Server 2005索引视图提高性能一,通常,这些视图的主要作用是: 提供一种安全机制,EXPAND 视图有助于消除因使用索引视图而导致的锁争用,在测试应用程序时,将用户限制到一个或多个基表的某个数据子集中,
一、索引视图
  
   多年以来,MicrosoftSQL Server一直支持创建称为视图的虚拟表。通常,这些视图的主要作用是:
  
   提供一种安全机制,将用户限制到一个或多个基表的某个数据子集中。
  
   提供一种机制,允许开发人员自定义用户通过逻辑方式查看存储在基表中的数据的方式。
  
   通过 SQL Server 2000,SQL Server 视图的功能得到了扩展,实现了系统性能方面的收益。可在视图上创建唯一的聚集索引及非聚集索引,来提高最复杂的查询的数据访问性能。在 SQL Server 2000 和 2005 中,具有唯一的聚集索引的视图即为索引视图。本文所讨论的内容适用于 SQL Server 2005,其中有许多内容也适用于 SQL Server 2000。
  
   从数据库管理系统 (DBMS) 的角度看来,视图是对数据(一种元数据类型)的一种描述。当创建了一个典型视图时,通过封装一个 SELECT 语句(定义一个结果集来表示为虚拟表)来定义元数据。当在另一个查询的 FROM 子句中引用视图时,将从系统目录检索该元数据,并替代该视图的引用扩展元数据。视图扩展之后,SQL Server 查询优化器会为执行查询编译一个执行计划。查询优化器会搜索针对某个查询的一组可能的执行计划,并根据对执行每个查询计划所需的实际时间的估计,选择所能找到的成本最低的计划。
  
   对于非索引视图,解析查询所必需的视图部分会在运行时被具体化。任何计算(比如:联接或聚合)都在每个引用视图的查询执行时完成1。在视图上创建了唯一的聚集索引后,该视图的结果集随即被具体化,并保存在数据库的物理存储中,从而在执行时节省了执行这一高成本操作的开销。
  
   在查询执行中,可通过两种方式使用索引视图。查询可直接引用索引视图,或者更重要的是,如果查询优化器确定该视图可替换成本最低的查询计划中的部分或全部查询,那么就可以选定它。在第二种情况中,使用索引视图替代基础表及其一般索引。不必在查询中引用视图以使查询优化器在查询执行时使用该视图。这使得现有的应用程序可以从新创建的索引视图中受益,而不必进行更改。
  
   注意 索引视图是 SQL Server 2000 和 2005 各版本的一个功能。在 SQL Server 2000 和 2005 的 Developer 和 Enterprise 版本中,查询处理器可使用索引视图来解析结构上与该视图相匹配的查询,即便不按名称来引用视图。在其他版本中,必须按名称来引用视图,并对视图引用使用 NOEXPAND 提示来查询索引视图的内容。
  
   通过索引视图改善性能
  
   运用索引提高查询性能不算是一个新概念;但是,索引视图提供了一些借助标准索引无法取得的性能收益。索引视图可通过以下方式提高查询性能:
  
   可预先计算聚合并将其保存在索引中,从而在查询执行时,最小化高成本的计算。
  
   可预先联接各个表并保存最终获得的数据集。
  
   可保存联接或聚合的组合。
  
   该图说明了当查询优化器使用索引视图时,通常所能取得的性能改进。所列举的查询在复杂性上有所不同(比如:聚合计算的数量、所用表的数量或谓词的数量)并包含来自真实的生产环境的具有数百万行的表。

  在视图上使用非聚集索引
  
   其次,视图上的非聚集索引可提供更好的查询性能。与表上的非聚集索引类似,视图上的非聚集索引可提供更多选项,供查询优化器在编译过程中选择。例如,如果查询包含聚集索引所未涉及的列,那么优化器可在计划中选择一个或多个辅助索引,避免对索引视图或基表进行费时的完全扫描。
  
   对架构添加索引会增加数据库的开销,因为索引需要持续的维护。在索引数量和维护开销间寻求适当的平衡点时,应谨慎权衡。
  
   二、应用索引视图的优点
  
   在实施索引视图前,分析数据库工作负荷。运用查询及各种相关工具(比如:SQL Profiler)方面的知识来确定可从索引视图获益的查询。频繁发生聚合和联接的情况最适合使用索引视图。无论是否频繁发生,只要某个查询需要很长的响应时间,同时快速获得响应的开销很高,那么就适合使用索引视图。例如,一些开发人员发现为高级主管们在月末运行的报告,创建预先计算和存储查询的应答的索引视图很有用。
  
   不是所有的查询都能从索引视图中获益。与一般索引类似,如果未使用索引视图,就无法从中受益。在这种情况下,不仅无法实现性能改善,而且会在磁盘空间、维护和优化方面产生额外的成本。然而,当使用索引视图时,可大大改善(在数量级上)数据访问。这是因为查询优化器使用存储在索引视图(大幅降低了查询执行的成本)中预先计算的结果。
  
   查询优化器仅考虑对具有高成本的查询使用索引视图。从而避免出现这样的情况:在查询优化成本高于使用索引视图所节约的成本时尝试匹配各种索引视图。在成本少于 1 的查询中很好使用索引视图。
  
   从实施索引视图中获益的应用程序包括:
  
   决策支持工作负荷
  
   数据集市
  
   数据仓库
  
   联机分析处理 (OLAP) 存储和源
  
   数据挖掘工作负荷
  
   从查询类型和模式方面来看,获益的应用程序一般包含:
  
   大型表的联接和聚合
  
   查询的重复模式
  
   几组相同或重叠的列上的重复聚合
  
   相同键上相同表的重复联接
  
   以上各项的组合
  
   相反,执行许多写入操作的联机事务处理 (OLTP) 系统或者频繁更新的数据库应用程序可能无法运用索引视图,因为同时更新视图和底层基表会带来更高的维护成本。
  
   查询优化器如何使用索引视图
  
   SQL Server 查询优化器自动决定何时对给定的查询执行使用索引视图。不必在查询中直接引用视图以供优化器在查询执行计划中使用。所以,现有的应用程序可运用索引视图,而不用更改应用程序本身;只是必须创建索引视图。
  
   优化器考虑事项
  
   查询优化器通过考虑几个条件来决定索引视图能否涵盖整个或部分查询。这些条件对应查询中的一个 FROM 子句并由下列这几个部分组成:
  
   查询 FROM 子句中的表必须是索引视图 FROM 子句中的表的超集。
  
   查询中的联接条件必须是视图中的联接条件的超集。
  
   查询中的聚合列必须可从视图中的聚合列的子集派生。
  
   查询选择列表中的所有表达式必须可从视图选择列表或未包含在视图定义中的表派生。
  
   如果与其他谓词所匹配的行的超集相匹配,那么该谓词将归入另一个谓词。例如,“T.a=10”归入“T.a=10 and T.b=20”。任何谓词都可归入其自身。视图中限制表值的那部分谓词必须归入查询中限制相同表的那部分谓词。此外,必须以 SQL Server 可验证的方式实现这一点。
  
   属于视图定义中的表的查询搜索条件谓词的所有列必须出现在下列视图定义的一项或多项中:
  
   1.一个 GROUP BY 列表。
  
   2.视图选择列表(如不存在 GROUP BY)。
  
   3.视图定义中相同或等价的谓词。
  
   情况 (1) 和 (2) 允许 SQL Server 对视图的列应用查询谓词,以便进一步限制视图的列。情况 (3) 比较特殊。在这种情况下,不需要对列进行筛选,因此该列不必出现在视图中。
  
   如果查询不止包含一个 FROM 子句(子查询、派生表、UNION),优化器可能选择几个索引视图来处理查询,并将它们应用到不同 FROM 子句。2
  
   本文档的末尾提供了涉及这些情况的具体查询。推荐的最佳实务是让查询优化器决定在查询执行计划中使用哪些索引(如果有的话)。
  
   使用 NOEXPAND 视图提示
  
   当 SQL Server 处理按名称引用视图的查询时,视图的定义只有在仅引用基表时才会被正常扩展。这个过程称为视图扩展。其属于一种宏扩展形式。
  
   NOEXPAND 视图提示可强制查询优化器将视图视为带有聚集索引的普通表。其可防止视图扩展。只有在 FROM 子句中直接引用索引视图,才会应用 NOEXPAND 提示。例如,
  
   SELECT Column1, Column2, ...FROM Table1, View1 WITH (NOEXPAND) WHERE ...如要确保让 SQL Server 通过自己读取视图而不是从基表读取数据来处理查询,那么可使用 NOEXPAND。如果出于某种原因,SQL Server 选择了一个查询计划来对基表处理查询,而您想让其使用视图,那么可以考虑使用 NOEXPAND。必须在除 Developer 和 Enterprise 版本外的 SQL Server 的所有版本中使用 NOEXPAND 来让 SQL Server 直接对索引视图处理查询。可以看到 SQL Server 为计划的图形表达式选择了一个使用 SQL Server Management Studio 工具的显示预计的执行计划功能的语句。或者,可以看到使用 SHOWPLAN_ALL、SHOWPLAN_TEXT 或 SHOWPLAN_XML 的不同的非图形表达式。参阅 SQL Sever 联机丛书中有关 SHOWPLAN 的不同版本的相关讨论。
  
   使用 EXPAND VIEWS 查询提示
  
   处理按名称引用视图的查询时,除非对视图引用添加 NOEXPAND 提示,否则 SQL Server 总会扩展视图。该提示会尝试匹配索引视图和扩展查询,除非在查询末尾的一个 OPTION 子句中指定 EXPAND VIEWS 查询提示。例如,假设数据库中有一个索引视图 View1。在下方的查询中,根据其逻辑定义(其 CREATE VIEW 语句)对 View1 进行了扩展,然后 EXPAND VIEWS 选项会阻止在计划中使用 View1 的索引视图来解析该查询。
  
   SELECT Column1, Column2, ... FROM Table1, View1 WHERE ...
   OPTION (EXPAND VIEWS)
  
   如要确保让 SQL Server 通过从查询所引用的基表直接访问数据来处理该查询,而不必访问索引视图,那么可使用 EXPAND VIEWS。在某些情况下,EXPAND 视图有助于消除因使用索引视图而导致的锁争用。在测试应用程序时,NOEXPAND 和 EXPAND VIEWS 都可帮助用户在使用和不使用索引视图的情况下进行性能评估。

1 2 3  下一页

Tags:SQL Server 索引

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接