神秘的 DB2 排序

核心提示：在本文中，我将讨论一种奇怪的现象：从 SQL 语句中删除 ORDER BY 等排序语法实际上可能在访问路径中引入排序，神秘的 DB2 排序，而添加排序语法实际上可能消除访问路径中的排序，神秘的 plan_table 信息在我从事 DB2 的早期，可以使用索引按照索引列的次序返回表数据，例如，对于发现性能问题最有帮助的工

在本文中，我将讨论一种奇怪的现象：从 SQL 语句中删除 ORDER BY 等排序语法实际上可能在访问路径中引入排序，而添加排序语法实际上可能消除访问路径中的排序。

神秘的 plan_table 信息

在我从事 DB2 的早期，对于发现性能问题最有帮助的工具之一是 Explain 。最初，我发现 plan_table 中的许多列很神秘，令人费解。我花了很多时间试图弄明白为什么 DB2 优化器在某些情况下执行数据排序，而在其他情况下不执行。我研究了非常简单的包含排序语法的 SQL 语句，比如包含 ORDER BY 子句的简单 CURSOR，想要查明为什么在某些情况下 8 个 plan_table 排序标志都是 N，而对于非常相似的 SQL，SORTC_ORDERBY 标志却是 Y 。

我注意到，无论 DB2 是否执行排序来满足 ORDER BY 的要求，数据都会按照正确的次序返回。这个发现和 plan_table 中的索引使用信息最终让我得出了一个结论：ORDER BY 可能会导致数据排序，也可能不会。

这表明，当 DB2 不执行排序时，DB2 选用按照所需的次序返回表行的索引。当 DB2 执行排序时，DB2 要么选择不按照所需的次序返回数据的索引，要么选择能够按照所需的次序返回数据的索引，但是以某种方式使用它，导致返回的数据不符合所需的次序（后一种情况是需要注意的要点）。

索引是有序的列表，可以使用索引按照索引列的次序返回表数据。例如，可以使用 lastname、firstname 和 middle_initial 上的索引避免许多数据排序。下面是几个示例：

　Select　...................　
　from　employee_master　
　Where　lastname　=　:hvlastname　
　Order　by　firstname,　middle_initial　
　Select　...................　
　from　employee_master　
　Where　lastname　between　=　:hvlastname1　
　and　:hvlastname2　
　Order　by　lastname,　firstname　
　Select　...................　
　from　employee_master　
　Where　workdept　in　('A01',　'B22',　'B46')　
　And　lastname　>=　:hvlastname　
　Order　by　lastname