WEB开发网      濠电姷鏁告繛鈧繛浣冲洤纾瑰┑鐘宠壘閻ょ偓銇勯幇鍫曟闁稿鍠愰妵鍕冀閵娧佲偓鎺楁⒒閸曨偄顏柡宀嬬畱铻e〒姘煎灡绗戦梻浣筋嚙濮橈箓顢氳濠€浣糕攽閻樿宸ュΔ鐘叉啞缁傚秹宕滆绾惧ジ寮堕崼娑樺缂佹宀搁弻鐔风暋閻楀牆娈楅梺璇″枓閺呯姴鐣疯ぐ鎺濇晝闁靛牆妫欓蹇旂節閻㈤潧浠﹂柛銊ョ埣楠炴劙骞橀鑲╋紱闂佽宕樼粔顔裤亹閹烘挸浜归梺缁樺灦閿曗晛螞閸曨垱鈷戦柟鑲╁仜婵″ジ鎮楀☉鎺撴珖缂侇喖顑呴鍏煎緞濡粯娅囬梻浣瑰缁诲倿寮绘繝鍥ㄦ櫇闁稿本绋撻崢鐢告煟鎼淬垻鈯曢柨姘舵煟韫囥儳绋荤紒缁樼箖缁绘繈宕橀妸褌绱濋梻浣筋嚃閸ㄤ即宕弶鎴犳殾闁绘梻鈷堥弫鍌炴煕閳锯偓閺呮瑧妲愬Ο琛℃斀闁绘劕妯婇崵鐔封攽椤旇棄鍔ら摶鐐烘煕閺囥劌澧柛娆忕箻閺屽秹宕崟顒€娅g紓浣插亾濠㈣泛顑囩粻楣冩煙鐎涙ḿ绠橀柨娑樼У椤ㄣ儵鎮欓鍕紙闂佽鍠栫紞濠傜暦閹偊妲诲┑鈩冨絻椤兘寮诲☉銏犖╅柕澶堝労閸斿绱撴担绋库偓鍝ョ矓瑜版帒鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘 ---闂傚倸鍊烽悞锔锯偓绗涘厾娲煛閸涱厾顔嗛梺璺ㄥ櫐閹凤拷
开发学院数据库DB2 DB2 9中15个pureXML性能最佳实践 阅读

DB2 9中15个pureXML性能最佳实践

 2010-02-18 15:01:05 来源:WEB开发网 闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�闂傚倸鍊风粈渚€骞夐敓鐘插瀭闁汇垹鐏氬畷鏌ユ煙閹殿喖顣奸柛搴$У閵囧嫰骞掗幋婵冨亾閻㈢ǹ纾婚柟鐐灱濡插牊绻涢崱妤冃℃繛宀婁簽缁辨捇宕掑鎵佹瀸闂佺懓鍤栭幏锟�濠电姷鏁告慨顓㈠箯閸愵喖宸濇い鎾寸箘閹规洟姊绘笟鈧ḿ褍煤閵堝悿娲Ω閳轰胶鍔﹀銈嗗笂閼冲爼鍩婇弴銏$厪闁搞儮鏅涙禒褏绱掓潏鈺佷槐闁轰焦鎹囬弫鎾绘晸閿燂拷闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�  闂傚倸鍊烽懗鑸电仚缂備胶绮〃鍛村煝瀹ュ鍗抽柕蹇曞У閻庮剟姊虹紒妯哄闁圭⒈鍋嗛惀顏囶樄闁哄本娲樼换婵婄疀閺囩姷鐛ラ梻浣哄帶婢瑰﹥绂嶅⿰鍫氣偓鏃堝礃椤忎礁浜鹃柨婵嗛婢ь喖霉閻樻瑥瀚粻楣冩煕椤愩倕鏋庨柣蹇嬪劜閵囧嫰寮村Ο鍝勫Е濡炪們鍨洪悷鈺呭箖閳╁啯鍎熼柕鍥у簻閹凤拷
核心提示:提示7:在XPath 表达式中,尽可能使用全限定路径假设有一个包含 XML 列的表create table customer(info XML);要管理具有以下结构的“customerinfo” 文档:清单 3. 示例 XML 文档<customerinfo Cid="1004&

提示7:在XPath 表达式中,尽可能使用全限定路径

假设有一个包含 XML 列的表

create table customer(info XML);

要管理具有以下结构的“customerinfo” 文档:

清单 3. 示例 XML 文档

<customerinfo Cid="1004">
  <name>Matt Foreman</name>
  <addr country="Canada">
     <street>1596 Baseline</street>
     <city>Toronto</city>
     <state>Ontario</state>
     <pcode>M3Z-5H9</pcode>
  </addr>
  <phone type="work">905-555-4789</phone>
  <phone type="home">416-555-3376</phone>
</customerinfo>

如果要检索客户的电话号码或他们所居住的城市,无论使用XQuery 还是SQL/XML,都有多种可能的路径表达式可获得该数据。通过 /customerinfo/phone和 //phone 都可以获得电话号码。同样,/customerinfo/addr/city和 /customerinfo/*/city 都返回城市。为了得到最佳的性能,使用全限定路径比使用*或// 更可取,因为使用全限定路径可以使 DB2 直接导航到所需的元素,而忽略文档中不相关的部分。

换句话说,如果您知道所需的元素位于文档中的什么位置,那么以全限定路径的形式提供位置信息会比较有帮助。如果请求 //phone 而不是/customerinfo/phone,那么就是在请求文档中任何地方的phone 元素。这需要 DB2 向下导航到文档的"addr" 子树中,在文档的任何级别上查找 phone 元素,而这本是可以避免的开销。

注意,*和 // 还可能导致不需要的或期望之外的查询结果。例如,如果有些 “customerinfo” 文档还包含 “assistant” 信息,就像下面的文档一样。那么路径 //phone 将返回客户的电话号码和助手的电话号码,而没有将它们区分开。从查询结果中无法知道是客户的电话号码还是助手的电话号码,甚至会把助手的电话号码当作客户的电话号码来处理。

清单 4. 文档中多个层次中的phone和 name 元素

<customerinfo Cid="1004">
  <name>Matt Foreman</name>
  <addr country="Canada">
     <street>1596 Baseline</street>
     <city>Toronto</city>
     <state>Ontario</state>
     <pcode>M3Z-5H9</pcode>
  </addr>
  <phone type="work">905-555-4789</phone>
  <phone type="home">416-555-3376</phone>
  <assistant>
     <name>Peter Smith</name>
     <phone type="home">416-555-3426</phone>
   </assistant>
</customerinfo>

总而言之,在路径表达式中避免使用*和 //,尽量使用全限定路径。

提示8:定义倾斜的XML 索引,并避免为任何东西都建索引

假设我们的查询常常根据客户姓名搜索 “customerinfo” 文档。客户姓名元素上的索引可以大大提高那些查询的性能。让我们来看看下面的例子:

清单 5. 利用索引为根据客户姓名搜索文档提供支持

create table customer(info XML);
create index custname1 on customer(info)
generate key using xmlpattern '/customerinfo/name' as sql varchar(20);
create index custname2 on customer(info)
generate key using xmlpattern '//name' as sql varchar(20);
select * from customer
where xmlexists('$i/customerinfo[name = "Matt Foreman"]' passing info as $i);

上面定义的两个索引都适合用于客户姓名上的XMLEXISTS 谓词的计算。但是实际上,索引 custname2 比索引 custname1 更大一些,因为它不仅包含客户姓名的索引条目,而且包括助手姓名的索引条目。只是因为XML 模式 //name 与文档中任何地方的name 元素相匹配。但是,如果我们永远不需要根据助手姓名来进行搜索,那么就不需要为它们编索引。

对于读操作,索引 custname1 更小一些,因此可能带来更好的性能。对于插入、更新和删除操作,索引 custname1 只会引起用于客户姓名的维护开销,而索引 custname2 则需要用于客户和助手姓名的索引维护。如果想得到最佳的插入/更新/删除性能,并且不需要根据助手姓名进行基于索引的访问,那么当然不想花费额外的代价。

另外,请考虑下面的heavyIndex 索引,它 “为任何东西编索引”。它包含每个文本节点(即 XML 列中的每个 XML 文档中的每个叶子元素值)的索引条目。在插入/更新/删除操作期间,那样的索引维护起来非常消耗成本,因而通常不推荐使用这样的索引。惟一的例外是,具有较少写活动和不可预测的查询工作负载的应用程序,这种应用程序难于定义更明确的索引。

create index heavyIndex on customer(info)
generate key using xmlpattern '//text()' as sql varchar(20);

总而言之,在定义 XML 索引时,应该尽可能精确一点,尽量避免使用*和 //。

上一页  1 2 3 4 5 6 7 8  下一页

Tags:DB pureXML 性能

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