神秘的 DB2 排序

核心提示： 在其他许多情况下，这个索引也有助于避免排序，神秘的 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 子句条件可以应用于索引？哪些必须应用于表数据？用户是否关心数据的次序？是否可以只使用索引获取所有数据，而不必读取表数据？