用DB2 pureXML执行不区分大小写的高效搜索

核心提示： 现在，如果用 Visual Explain 或 db2exfmt 解释此查询，用DB2 pureXML执行不区分大小写的高效搜索(5)，就会看到这个不区分大小写的搜索使用了索引：图 3. 在不区分大小写的数据库中查询 Paris 的所有客户的 Explain Plan本节介绍的方法有一个潜

现在，如果用 Visual Explain 或 db2exfmt 解释此查询，就会看到这个不区分大小写的搜索使用了索引：

图 3. 在不区分大小写的数据库中查询 Paris 的所有客户的 Explain Plan

本节介绍的方法有一个潜在的缺点：整个数据库中所有表中的所有列中的所有数据都是不区分大小写的。不可能以区分大小写的方式处理特定的表或列。要么都区分大小写，要么都不区分。

注意，不区分大小写只应用于元素和属性值，而不应用于标记名本身。XML 标记和路径表达式仍然是区分大小写的。例如，XPath 表达式 /Customer/city（小写 “c”）和 /Customer/City（大写 “C”）是不同的。后者不匹配示例数据中的任何元素，因为示例数据中的 元素名是小写的。

性能

在数据库中使用定制的排序规则可能影响查询性能，因为在选择更宽松的 UCA 设置时，匹配的字符串数量可能会增加。换句话说，在不区分大小写的数据库中，字符串比较的开销可能会略微增加。为了查明区分大小写的和不区分大小写的数据库之间的性能差异，我们创建了一个常规数据库（区分大小写）和一个不区分大小写的数据库。然后，插入来自 TPoX 基准测试的 20,000 个 CustAcc 文档并在这两个数据库中对各种查询进行测试。

对于只涉及少量到中等数量的行的查询，两个测试数据库之间的性能差异可以忽略不计。我们发现涉及大量行的查询的性能差异比较大，比如对所有 20,000 个 XML 文档进行全表扫描并对每个文档比较字符串。在不区分大小写的数据库中，这种查询花费的时间增加了 5% 到 8%。因此，实现不区分大小写的搜索需要付出的代价并不大。

结束语

以不区分大小写的方式搜索 DB 2 数据有多种方法，比如使用生成的列（请参见 参考资料）。尽管这些方法都适合关系数据，但是不适合查询 XML 数据。以不区分大小写的方式处理 XML 数据的最佳方法是用定制的 Unicode 排序规则创建数据库。这使数据库中的所有字符串值比较都采用不区分大小写的方式，避免妨碍使用 XML 索引和关系索引。由于不区分大小写或重音符号，会增加匹配的字符串，但是增加的开销非常低。