神秘的 DB2 排序

　2009-11-16 00:00:00　来源：WEB开发网　闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�

闂傚倸鍊风粈渚€骞夐敓鐘插瀭闁汇垹鐏氬畷鏌ユ煙閹殿喖顣奸柛搴＄У閵囧嫰骞掗幋婵冨亾閻㈢ǹ纾婚柟鐐灱濡插牊绻涢崱妤冃℃繛宀婁簽缁辨捇宕掑鎵佹瀸闂佺懓鍤栭幏锟�

濠电姷鏁告慨顓㈠箯閸愵喖宸濇い鎾寸箘閹规洟姊绘笟鈧ḿ褍煤閵堝悿娲Ω閳轰胶鍔﹀銈嗗笂閼冲爼鍩婇弴銏＄厪闁搞儮鏅涙禒褏绱掓潏鈺佷槐闁轰焦鎹囬弫鎾绘晸閿燂拷闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�　　闂傚倸鍊烽懗鑸电仚缂備胶绮〃鍛村煝瀹ュ鍗抽柕蹇曞У閻庮剟姊虹紒妯哄闁圭⒈鍋嗛惀顏囶樄闁哄本娲樼换婵婄疀閺囩姷鐛ラ梻浣哄帶婢瑰﹥绂嶅⿰鍫氣偓鏃堝礃椤忎礁浜鹃柨婵嗛婢ь喖霉閻樻瑥瀚粻楣冩煕椤愩倕鏋庨柣蹇嬪劜閵囧嫰寮村Ο鍝勫Е濡炪們鍨洪悷鈺呭箖閳╁啯鍎熼柕鍥у簻閹凤拷

核心提示： 在其他许多情况下，这个索引也有助于避免排序，神秘的 DB2 排序(2)，DB2 的思考方式假设我们定义了一个索引，在执行包含适当的 ORDER BY 子句的 SQL 时，它还要考虑其他许多东西，尤其是 SQL 的语法，DB2 可以使用它避免排序，再假设还有其他索引可供选择

在其他许多情况下，这个索引也有助于避免排序。

DB2 的思考方式

假设我们定义了一个索引，在执行包含适当的 ORDER BY 子句的 SQL 时，DB2 可以使用它避免排序。再假设还有其他索引可供选择。那么，DB2 为什么会选择一个索引，而不选择另一个呢？有许多原因：

SQL 语句中有排序语法而且索引之一可以避免排序。

有一个或多个 WHERE 子句谓词，DB2 可以对此索引应用这些谓词，从不符合条件的行中过滤出符合条件的行。

选择的所有列和 WHERE 子句中提到的所有列（实际上，就是 SQL 语句中任何地方提到的所有列）都包含在此索引中。 DB2 可以执行只索引访问，完全避免读取表。

在一个索引中级别数量是 4 ；在另一个索引中是 2 。

一个索引的次序与表数据相同，而其他索引不是。

SQL 语句中有 OPTIMIZE FOR 1 ROW 。

其他许多原因。

同时存在以上多个原因。

当 DB2 为 SQL 选择访问路径时，它会衡量使用不同索引的好处，并考虑根本不使用任何索引（表空间扫描）。

SQL 选项

现在看看当 DB2 评估前面给出的一个 SQL 语句时会发生什么：

　Select　workdept,　lastname,　jobcode　　from　employee_master　　Where　workdept　in　('A01',　'B22',　'B46')　　And　lastname　>=　:hvlastname　　Order　by　lastname　

DB2 可以使用三个索引之一获取表行：

lastname、firstname 和 middle_initial 上的 Index1

workdept 和 lastname 上的 Index2

jobcode、workdept 和 lastname 上的 Index3

DB2 根据 I/O、CPU 和排序开销计算使用每个索引的成本。它会估计对索引和对表的 Get Pages 操作数量。通过检查基数（cardinality）统计数据，估计在应用和匹配索引谓词之后可能有多少个索引 RID 符合条件。检查索引的深度和广度。计算在一个索引页面上有多少索引行，以及在一个表页面上有多少表行。按照与表次序的关系评估索引次序。它还要考虑其他许多东西，尤其是 SQL 的语法。选择了哪些列？哪些 WHERE 子句条件可以应用于索引？哪些必须应用于表数据？用户是否关心数据的次序？是否可以只使用索引获取所有数据，而不必读取表数据？