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

核心提示：提示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 索引时，应该尽可能精确一点，尽量避免使用*和 //。