db2 galileo query performance enhancements...db2 version 10.1 查询性能改进第 5 页（共 18...

IBM® DB2® for Linux®, UNIX®, and Windows®

®

DB2 V10.1 查询性能改进

David Sky

高级技术作家

DB2 for Linux, UNIX, and Windows

.

发布时间：2012 年 4 月

DB2 Version 10.1 查询性能改进第 2 页（共 18 页）

执行摘要 .............................................................................................................. 4

常见 SQL 语句的查询性能改进......................................................................... 5

Partial Early Distinct (PED) ........................................................................ 5

Partial Early Aggregation (PEA) ................................................................ 6

查询优化器目前选中的散列连接适用于范围更广的 SQL 查询 ............... 6

降低由查询生成的网络通信流量的估算成本........................................... 6

RUNSTATS 和数据库统计信息改进.................................................................. 7

RUNSTATS 现在支持索引采样 .................................................................... 7

RUNSTATS 中的 DETAILED 选项现在会默认使用采样........................... 7

可以对所有背景统计信息收集使用自动采样............................................... 8

增加的 VIEW 参数（与 TABLE 同义） ....................................................... 8

如果未指定模式名称，则使用默认的假设模式名称.................................... 8

优化配置文件支持注册表变量和不精确匹配...................................................... 8

统计视图改进了统计信息和查询优化器的统计信息收集.................................. 9

包含复杂表达式的谓词 .................................................................................... 9

减少统计视图的数量........................................................................................ 9

在统计视图上收集到的列组统计信息 ............................................................. 9

统计视图的自动统计信息收集......................................................................... 9

内部分区并行性改进............................................................................................... 10

重新平衡不均衡的子代理工作负载 ................................................................. 10

对范围分区表和索引进行并行扫描.................................................................. 10

限制并行性程度以针对事务型工作负载进行优化的能力............................. 10

通过更高效的数据和索引预取提升查询性能 ........................................................11

具有复合索引的表查询性能改进............................................................................ 12


问题：索引间隙 .............................................................................................. 12

解决方案：跳转扫描实现............................................................................... 13

运行 AIX 的大型 POWER7 系统的内存共享改进 ............................................. 13

改进了基于星型模式查询的性能 ......................................................................... 14

改进的星型模式检测........................................................................................ 14

新的 zigzag join 方法 ...................................................................................... 15

结束语 ...................................................................................................................... 16

参考资料................................................................................................................... 16

投稿者....................................................................................................................... 16

公告 ........................................................................................................................... 17

商标 ...................................................................................................................... 18


执行摘要在 DB2® 的每个版本中，IBM 一直非常关注那些客户期望的出色 SQL 查询优化和性能的

维护。这个版本也是如此，此版本还增加了下列改进：

• 常见 SQL 查询类型（包括基于星型模式的查询）的自动性能改进

• 客户可用来进一步提高其 SQL 查询速度的新功能

• 客户可用来降低优化某种 SQL 查询类型复杂性的新功能

• 运行 AIX® 的大型 POWER7® 系统上的内存共享改进

本文将介绍这些增加内容，您可以访问 DB2 Version 10.1 Information Center（链接为

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp）了解更多信息，这可以帮

助您更好地了解在自己的数据库环境中如何充分利用这些改进。

http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp


常见 SQL 语句的查询性能改进

DB2 Version 10.1 中包含了许多性能改进，这些改进可以提高许多查询的查询速度。

这些改进是自动的；无需对所需的 SQL 语句进行任何配置设置或更改。

Partial early distinct (PED)

目前我们使用了一种高效的散列函数，在查询处理的早期阶段删除部分副本。这可能无法删除所有副本，

但会减少稍后的查询评估阶段中必须处理的数据数量。删除一些初始副本行将会提高查询速度，并降低耗

尽堆内存的可能性，从而消除了在这些情况下进行临时存储时对那些相对缓慢的磁盘空间的需要。这种改

进被称为 Partial Early Distinct (PED)。

要确定此改进是否可用于特定查询，请激活 Explain 工具并运行查询。EXPLAIN_ARGUMENT 表中的

新值表示将此新功能应用于查询的时间：

• ARGUMENT_TYPE 列 = UNIQUE

• 现在 ARGUMENT_VALUE 列还包含一个值：HASHED PARTIAL，它表示已使用了此新功能

db2exfmt 工具还会在其输出中显示 HASHED PARTIAL，如下列示例所示：

6) UNIQUE: (Unique)

Cumulative Total Cost: 132.519

Cumulative CPU Cost: 1.98997e+06

...

...

Arguments:

---------

JN INPUT: (Join input leg)

INNER

UNIQKEY : (Unique Key columns)

1: Q1.C22

UNIQKEY : (Unique Key columns)

2: Q1.C21

UNIQUE : (Uniqueness required flag) HASHED PARTIAL


Partial Eearly Aggregation (PEA) 与 Partial Early Distinct (PED) 类似，Partial Early Aggregation (PEA) 是在查询处理早期进行部分数据聚

合的一种尝试。尽管不太可能在此时进行所有聚合，但是至少可以减少稍后的查询评估阶段中必须处理的

数据数量。

要确定 Partial Early Aggregation 是否可用于特定查询，请激活 Explain 工具并运行查询。

EXPLAIN_ARGUMENT 表中的新值表示将此新功能应用于查询的时间：

• ARGUMENT_TYPE 列 = AGGMODE

• 现在 ARGUMENT_VALUE 列包含一个值：HASHED PARTIAL，它表示已使用了此新功能

db2exfmt 工具还会在其输出的 GRPBY 部分显示 HASHED PARTIAL，如果已在本部分查询中应用了

此新功能，那么还会在树视图中显示 pGRPBY。

查询优化器目前选中的散列连接适用于范围更广的 SQL 查询在确定如何运行包含一个连接的 SQL 查询时，查询优化器会在三种基本连接策略之间选择。在许多情况

下，散列连接是最有效的方法，并且对于此版本，可以在更多情况下使用散列连接。

数据类型不匹配

即使连接中的两个列具有不同的数据类型，仍然可以考虑使用散列连接。这适用于除极端情况

外的所有情形。

连接谓词中使用的表达式

包含表达式的连接谓词不再限制嵌套式循环连接的连接方法。在此版本中，在 WHERE 子句包含一

个表达式的情况下，可以考虑使用散列连接，比如：WHERE T1.C1 = UPPER(T1.C3)

在这些情况下，会自动考虑散列连接。无需更改任何现有 SQL 查询即可利用这个改进的功能。注意，

散列连接会使用某种堆内存。

降低由查询生成的网络通信流量的估算成本查询优化器根据一系列信息来选择尽可能高效的访问计划。查询的估算通信成本已有所降低，优化器可以

更精确地判断并比较所有 CPU、IO 和通信成本。在许多情况下，这会提升查询性能。


查询的每个节点估算通信成本也已降低，比如解释元素 COMM_COST 和 FIRST_COMM_COST 返回的

通信。现在它们与现有的 CPU 和 IO 成本每节点计算更加一致。在评估不同的访问计划时，这使查询优

化器可以有效地平衡所有这三种成本的估算。这还会增加并行性，实现方法是：如果可能，将网络流量平

均分布给多个网络适配器。具体而言：

• 如果有多个网络适配器，则会返回数字最大的适配器累计通信成本。在之前的版本中，会返回整

个网络所传输的帧的总数。

• 这些值仅包含物理机之间的网络流量成本，不包括分区数据库环境中同一物理机上节点分区之间

的虚拟通信成本。

RUNSTATS 和数据库统计信息改进在某些情况下，需要对 RUNSTATS 命令进行大量改进，让统计信息收集变得更快。还简化了命令参

数。

相关的信息中心主题：

RUNSTATS command

RUNSTATS 现在支持索引采样现在 RUNSTATS 命令可以使用采样方法而不是通过扫描整个索引来收集索引统计信息。该命令通过新的

命令参数 INDEXSAMPLE 激活。界面类似于现有的 TABLESAMPLE 命令参数。新采样通常会缩短生成

统计信息所需的时间，采用的方法是：减少 RUNSTATS（当指定了 INDEXSAMPLE SYSTEM 时）处理

的叶节点总数，或者是减少 RUNSTATS（当指定了 INDEXSAMPLE BERNOULLI 时）处理的索引项总

数。

RUNSTATS 中的 DETAILED 选项现在会默认使用采样

从 DB2 Version 10.1 开始，收集详细索引统计信息的默认方法已经改变。在使用 DETAILED 选项时，不再

扫描整个索引，而是使用采样方法来收集统计信息。现在，此选项等同于 SAMPLED DETAILED 选项，出

于兼容性，已删除了 SAMPLED DETAILED 选项。在之前的版本中，为了通过扫描整个索引来收集详细的

索引统计信息，可以指定 UNSAMPLED 选项。

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0001980.html


可以对所有背景统计信息收集使用自动采样

现在，在大型表和统计视图中，可以对所有背景统计信息收集使用自动采样。通常情况下，采样数据所生

成的统计信息与扫描整个表或视图生成的统计信息一样精确，但是完成收集所需的时间和资源更少一些。

您可以使用新的 auto_sampling 参数来启用自动采样。

增加的 VIEW 参数（与 TABLE 同义）

RUNSTATS 命令现在支持 VIEW 命令参数。增加此参数是为了在视图上运行 RUNSTATS 时更直观一些。

该命令的运行方式与为视图指定 TABLE 参数一样。

如果未指定模式名称，则使用默认的假设模式名称

为提高 RUNSTATS 命令的易用性，无需再通过指定一个模式名称来指定完全限定对象名称。如果未指定

模式名称，则使用默认模式名称。

优化配置文件支持注册表变量和不精确匹配

现在，优化配置文件可用于设置特定注册表变量并支持不精确匹配。在编译查询语句时，不精确匹配可进

行更好的匹配。

在优化配置文件中，可使用 REGISTRY 元素中的 OPTION 元素设置注册表变量的子集。OPTION 元

素具有 NAME 和 VALUE 属性，它们指定了注册表变量及其值。可以在全局级别或语句级别（对于

具体语句来说）上设置多个注册表变量。

现在，除了精确匹配外，优化配置文件还支持不精确匹配。在匹配语句时，不精确匹配会忽略常量、主机

变量和参数标记。要在优化配置文件中指定索引匹配，请将 STMTMATCH 元素的 EXACT 属性值设置为

FALSE。可以在全局级别或语句级别上指定 STMTMATCH 元素。


SQL compiler registry variables in an optimization profile

Statement key and compilation key matching

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0058986.html



统计视图改进了统计信息和查询优化器的统计信息收集

统计视图有了新功能，DB2 查询优化器现在可使用这些新功能生成更好的访问计划，提升某些查询的性

能。

包含复杂表达式的谓词

现在，DB2 查询优化器可以在统计视图中使用表达式列（具有一个或多个函数的列）中的统计信息。在

之前的版本中，优化器仅可以为谓词中具有复杂表达式的查询的选择评估使用默认值。但是，从这一版

本开始，优化器可使用实际统计信息生成更好的访问计划。

减少统计视图的数量

现在，如果存在引用完整性约束并且在数据中定义了该限制，则可以减少获得星型连接查询的准确统计信

息所需的统计视图数量。现在可以创建一个统计视图，其中包含连接查询的许多列。根据引用完整性约

束，可从此统计视图推断出特定连接的统计信息。

在统计视图上收集到的列组统计信息

现在，DB2 查询优化器可以使用从统计视图（列组统计信息也是在该视图上收集的）收集到的统计信

息。组合使用列组统计信息和统计视图会改善访问计划，因为优化器可以使用从可能曲解的查询中收集

到的已调整统计信息。

统计视图的自动统计信息收集

现在，DB2 自动统计信息收集功能可以自动收集统计视图的统计信息。默认情况下不支持此功能，必须使

用新的数据库配置参数 auto_stats_view 启用此功能。必须使用 UPDATE 命令启用这个新参数，然后才能

自动从统计视图收集统计信息。通过自动统计信息收集功能来收集统计信息等同于发出下列命令：

runstats on view <view_name> with distribution。


Referential integrity constraints help reduce the number of statistical views

Statistics used from column group statistics on statistical views

Statistics used from expression columns in statistical views





内部分区并行性改进

DB2 查询优化器的一个目标是选择并行执行策略，保持子代理之间的数据均衡，让它们同等繁忙。在此版

本中，优化器的并行化功能已得到了进一步改善，支持更多的工作负载更好地利用多核处理器。

重新平衡不均衡的子代理工作负载

在执行查询时，数据过滤和数据倾斜可能会造成子代理之间的工作负载不均衡。不均衡工作负载的低效性

被连接 (join) 和其他计算开销很高的操作放大了。优化器在查询访问计划中查找不均衡的来源，并应用均

衡策略，确保在子代理之间平均分配工作。对于无序的外部数据流，优化器在外部使用 REBAL 运算符平

衡连接。对于有序的数据流（其中有序数据由索引访问或排序生成），优化器使用共享排序平衡数据。即

使排序溢到了临时表，也不会使用共享排序，因为排序溢出的成本很高。

对范围分区表和索引进行并行扫描

可以根据范围分区表运行并行表扫描，同样，也可以根据分区索引运行并行索引扫描。对于并行扫描，根

据索引密钥值和密钥值的密钥条目数量，可以将分区索引划分为各种记录范围。当并行扫描开始时，子代

理会分配记录范围，在子代理完成该范围后，会分配一个新范围，并会按顺序扫描索引分区，子代理可以

随时扫描无限制的索引分区，而不用等待另一方。根据数据分区删除分析，只扫描与查询相关的索引分区

子集。

限制并行性程度以针对事务型工作负载进行优化的能力

现在，各应用程序或工作负载可以动态限制内部分区并行性的程度，优化正在执行的查询类型的性能。在

之前的 DB2 版本中，只能控制整个实例的并行性程度（以及它是启用或禁用的）。启用或禁用并行性还要

求重启实例。在具有混合工作负载的数据库服务器上，需要一种更加灵活的内部分区并行性控制方法。事

务型工作负载通常包含简短的插入、更新和删除事务，不会从并行化中受益。当启用内部分区并行性时，

会有一些处理开销，这为事务型工作负载带来了负面影响。但是，数据仓库工作负载会从并行化中获得极

大的受益，因为它们通常包括处理器密集型的长时间运行查询。

对于混合工作负载，借助事务型和数据仓库组件，您现在看可以配置数据库系统，提供适合各应用程序部

署某种工作负载时的并行设置。可以通过应用逻辑或 DB2 工作负载管理器（不需要应用更改）控制并行设

置。


从数据库应用程序控制内部分区并行性：要从数据库应用程序中启用或禁用内部分区并行性，可以调用新

的 ADMIN_SET_INTRA_PARALLEL 过程。例如，下列语句支持内部分区并行性：

CALL ADMIN_SET_INTRA_PARALLEL('YES')

尽管会在当前事务中调用此过程，但要从下一个事务才开始生效，而且此过程仅适用于调用应用程序。由

ADMIN_SET_INTRA_PARALLEL 设置的内部分区并行性将重写 intra_parallel 配置参数中的值。

从 DB2 工作负载管理器控制内部分区并行性：要启用或禁用指定工作负载的内部分区并行性，可以设置

MAXIMUM DEGREE 工作负载属性。例如，下列语句禁用了名为 trans 的工作负载的内部分区并行

性：

ALTER WORKLOAD trans MAXIMUM DEGREE 1

在 ALTER WORKLOAD 语句后执行的工作负载的所有语句都将禁用内部分区并行性。使用 MAXIMUM

DEGREE 工作负载属性设置的内部分区并行性会重写 ADMIN_SET_INTRA_PARALLEL 的调用，并重写

intra_parallel 配置参数中的值。


Optimization strategies for intra-partition parallelism

通过更高效的数据和索引预取提升查询性能

DB2 Version 10.1 的特色功能为智能数据预取和智能索引预取，这提升了查询性能，降低了重新组织表和索引的需要。

在多次更改表数据或索引后，顺序数据或索引可能位于坏集群 (badly clustered) 数据页或低密度的索引叶

节点页 (leaf page) 上。在之前的版本中，这很可能会导致查询性能下降。这是因为序列检测预取的效率

更低了，原因是坏集群数据页的增加，以及索引叶节点页密度的降低。

智能数据预取仅适用于 ISCAN-FETCH 运行时，而智能索引预取适用于所有索引扫描，即使这些扫描是

ISCAN-FETCH 的一部分。优化器可以结合使用智能数据预取和智能索引预取，选择最佳索引和数据预取

方法。但是，智能数据预取和智能索引预取相互独立。

在 DB2 Version 10.1 中引入的新预取类型是预读取的，它用于高效地预取坏集群数据页和低密度索引页。

除了下列限制情况外，优化器选择预读取作为序列检测预取的备选方法。在运行时，当检测到序列检测预

取情况不是很好时，预取类型可能会从序列检测预取切换为预读取。预读取会提前查看索引，确定索引操作

将访问的准确数据页或索引叶节点页，并预取它们。而预读取提供索引扫描期间所需的所有数据页和索引叶

节点页（并且不会预取不需要的任何页），它还需要其他资源来定位这些页面。对于高度连续的数据或索

引，序列检测预取的性能通常会优于预读取。



智能数据预取是一种使用序列检测预取或预读取的方法，具体预取方法取决于数据聚类的程度。按顺序存储

数据页时会使用序列检测预取，而在出现坏集群数据页时会使用预读取。智能数据预取支持数据库系统利用

连续页面存储的数据的潜在性能优势，同时支持高效地预取坏集群数据。由于坏集群数据对查询性能不再有

害，因此这会减少表重组等昂贵操作的需要。

智能索引预取是一种使用序列检测预取或预读取的方法，具体预取方法取决于索引的密度。按顺序存储索引

时会使用序列检测预取，而在索引密度较低时，则会使用预读取。智能索引预取支持数据库系统利用按顺序

存储索引的潜在性能优势，同时支持高效地预取低密度索引。智能索引预取会减少索引重组等昂贵操作的需

要。

智能数据预取和智能索引预取支持仅适用于索引扫描操作，不支持 XML、扩展索引和 Text Search 文本索

引。在扫描全局范围集群表索引期间，不能使用智能数据预取，因为它们是逻辑索引而不是物理索引。此

外，对于智能数据预取，如果 ISCAN-FETCH 扫描全局范围分区索引，则不能使用数据预读取。如果在智

能数据预取的索引扫描期间评估了索引谓词，并且优化器确定没有太多行符合此索引扫描，则会禁用预读

取。智能索引预取也不能用于范围集群表索引。


Prefetching data into the buffer pool

具有复合索引的表查询性能改进现在，DB2 查询优化器可以创建其他访问计划，这些访问计划可能对于使用跳转扫描操作进行查询（在器

起始/终止键中具有索引间隙）更高效一些。例如，对于具有复合索引的表发出的包含多个谓词的查询而

言，索引间隙非常常见。跳转扫描消除了索引间隙避免策略（比如创建其他索引）的需要。

问题：索引间隙对于涉及多个即席查询的工作负载来说，通常很难通过优化数据库来获得高性能。这对具有复合（多列）

索引的表进行查询提出了一个特殊的挑战。理想情况下，查询的谓词与表的复合索引一致。这意味着每个

谓词都可以用作一个起始/停止键，从而缩小需要搜索的索引范围。当查询包含与复合索引一致的谓词时，

这称为索引间隙。正因为如此，索引间隙是查询而不是表索引的一个特征。



例如，考虑使用整数列 A、B 和 C 的表 T，并且在列 A、B 和 C 中定义了复合索引。现在，考虑对表 T

进行下列查询：

SELECT * FROM t WHERE A=5 AND C=10

此查询在复合索引中包含列 B 的索引间隙（这假设访问计划包含复合索引的索引扫描）。

在存在索引间隙的情况下，索引扫描很可能不得不处理许多不必要的键。索引非前导列的谓词很可能需要

单独应用于满足起始/停止键的索引的每个键。这会减慢索引扫描的速度，因为需要处理更多的行，并且需

要对每个键评估其他谓词。此外，DB2 必须按顺序检查大范围中的所有键。

为了避免索引间隙，您可以定义其他索引，以包含可能出现在工作负载中的查询谓词排列。这并不是

一种理想的解决方案，因为定义其他索引会生成数据库管理开销并使用存储容量。此外，对于具有许

多即席查询的工作负载来说，很难预测需要哪些索引。

解决方案：启用跳转扫描在 DB2 Version 10.1 中，在查询包含索引间隙时，查询优化器可以创建使用跳转扫描操作的访问计划。在

跳转扫描操作中，索引管理器在存在索引间隙的复合索引部分确定符合的键，并使用这些符合的键填充这

些间隙。最终结果是索引管理器将会跳过不会生成任何结果的索引部分。

注意：当评估查询时，可能出现查询优化器构建的访问计划不包含跳转扫描操作的情况，即使存在索引

间隙也是这样。如果查询优化器认为有比跳转扫描更有效的方法，则会出现这种情况。


Data access through index scans

index_jump_scans - Index jump scans monitor element

运行 AIX 的大型 POWER7 系统的内存共享改进现在，DB2 Version 10.1 系统可以确定运行 POWER7® 的 AIX® 系统上的硬件拓扑，通过有效共享内

存来提升查询性能。

如果将 DB2_RESOURCE_POLICY 变量设置为 AUTOMATIC，那么 DB2 数据库系统会自动确定硬件拓

扑，并将引擎分派单元 (engine dispatchable units, EDU) 分配给各种硬件模块，以便在需要访问内存同

一区域的多个 EDU 之间更高效地共享内存。


http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.mon.doc/doc/r0059299.html


此设置将在具有 16 个核心或更多核心的大型 POWER7 系统上使用，可以提升某些工作负载的查询性能。

在将此变量设置为 AUTOMATIC 之前和之后，最好运行工作负载的性能分析，以验证是否存在性能提升。


Performance variables

改进了基于星型模式查询的性能

星型模式性能改进包括改进的检测算法和新连接方法。改进的星型检测算法支持查询优化器基于星型模式

检测查询，并使用星型模式具体策略来提升这些查询的性能。此外，在数据仓库和数据集市环境中，要使

用星型模式提升查询性能，可以使用新的 zigzag join 方法连接一个或多个具有两个或多个维度表的事实

表。

改进的星型模式检测改进的新星型模式算法并不是根据表大小的分析来确定查询是否基于星型模式。相反，它依赖于维度/雪花

型表的主键、惟一索引或惟一约束，以及维度/雪花型表和事实表之间的连接谓词。改进的星型检测算法可

以识别查询块的多个星型。它会删除 DB2 Version 10.1 之前的星型检测算法实现的一些约束。如果新检测

方法无法检测查询是否基于星型模式，例如，如果在维度表上没有主键、惟一索引或惟一约束，则会使用旧

检测方法。

使用跳转扫描功能，查询优化器可以识别星型模式，即使是查询中丢失了连接谓词也是这样。

http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.regvars.doc/doc/r0005665.html


新的 zigzag join 方法在 DB2 Version 10.1 版本之前，有两个特定的策略来处理星型模式连接查询：

• Cartesian-hub 连接计划，该计划会计算 Cartesian 产品的维度，然后使用 Cartesian 产品的每行

内容来探测多列事实表索引。

• 星型连接计划，该计划通过维度预过滤事实表来生成半连接，为半连接的 AND 结果建立索引，然

后完成半连接。

在 DB2 Version 10.1 中，引入了名为 zigzag join (ZZJOIN) 的新连接方法，以便加快基于星型模式的查询

处理过程。

zigzag join 是一种连接方法，其中的事实表和星型模式中的两个或多个维度表是连接的，这样就可以使用

索引来访问事实表。这需要在每个维度表和事实表之间提供等式谓词。此连接方法会计算维度表的

Cartesian 产品行，实际上不会实物化 Cartesian 产品，并使用多列索引探测事实表，因此可以同时根据两

个或多个维度表过滤事实表。探测事实表会找到匹配的行。然后，zigzag join 可以从事实表索引返回下一

个值组合。此下一个值组合称为反馈，用于跳过了维度表的 Cartesian 产品提供的探测值，所以这些维度表

不会在事实表中找到匹配值。同时根据两个或多个维度表过滤事实表，并跳过已知的低效探测，它们使

zigzag join 成为查询大型事实表的一种高效方法。


Ensuring that queries fit the required criteria for the star schema join



结束语

本文旨在介绍 DB2 Version 10.1 中的新 SQL 查询性能改进。请访问本文所包含的链接，了

解有关新功能和改进功能的更多信息，以及如何将它应用于 SQL 查询和数据库环境。

参考资料 • DB2 Version 10.1 信息中心 -


• DB2 最佳实践 -

http://www.ibm.com/developerworks/data/bestpractices/

投稿者

David Sky

高级技术作家，IBM

IBM 开发人员、技术作家和编辑。


http://www.ibm.com/developerworks/data/bestpractices/


公告本信息是针对在美国提供的产品和服务而开发的。

IBM 可能未在其他国家/地区提供本文中介绍的产品、服务或功能。请咨询您当地的 IBM 销售代表，获

取有关您所在区域目前可用的产品和服务的信息。对 IBM 产品、计划或服务的任何引用不代表或暗示

仅可使用该 IBM 产品、计划或服务。可使用任何不侵犯 IBM 知识产权且具有类似功能的产品、计划或

服务。但是，评估和验证任何非 IBM 产品、计划或服务的操作是用户自己的责任。

IBM 可能已拥有或正在申请与本文档内容有关的各项专利。拥有本文不代表向您授予这些专利的任何许

可。您可以以书面形式将许可咨询发送到：

IBM Director of Licensing IBM Corporation

North Castle Drive Armonk, NY 10504-1785

U.S.A.

本段内容不适用于英国或这些规定与其本地法律不符的任何其他国家/地区：国际商业机器公司“按原

样”提供本文，不作任何明示或暗示的保证，包括但不限于对非侵权性、适销性或特定用途的适用性

的暗示担保。一些地区不允许在某些交易不作明示或暗示的保证，在此情况下，本条款可能不适用。

在不限制上述免责声明的前提下，对于与本文中提供的任何信息或建议的准确性、可靠性或可服务性相

关的内容，或者使用该信息或遵循此处提供的任何建议可能带来的任何结果，IBM 不提供任何担保或表

示。本文中包含的信息未进行任何正式 IBM 测试并按原样分发。对本信息的使用或此处的任何建议或

技术的实现是客户自己的责任，取决于客户评估它们并将它们整合到客户的操作环境中的能力。尽管

IBM 在特定的条件下对每项内容执行了准确性检查，但不保证在其他环境中会获得相同或类似的结果。

任何尝试针对自己的环境调整这些技术的人风险自负。

本文和此处包含的信息应该尽可能地与本文中探讨的 IBM 产品一起使用。

本信息可能包含技术错误或录入错误。此处的信息会定期更改；这些更改会合并到出版物的新版本

中。IBM 随时可能对本文中描述的产品和/或计划进行改进和/或更改，恕不另行通知。

本信息中对非 IBM 网站的任何引用仅供参考，不以任何方式用作对这些网站的认可。这些网站上的材料不是本 IBM 产品的材料的一部分，使用这些网站时风险自负。

IBM 可以以它认为合适且不会为您带来任何责任的任何方式使用或分发您提供的信息。

此处包含的任何性能数据都是在受控环境中确定的。因此，在其他操作环境中获得的数据可能会有明显

的不同。有些测量可能是在开发级的系统上进行的，因此不保证与一般可用系统上进行的测量结果相

同。此外，有些测量是通过推算而估计的，实际结果可能会有差异。本文档的用户应当验证其特定环境

的适用数据。


与非 IBM 产品相关的信息是从这些产品的提供商、他们发布的公告或其他公共可用来源获得的。IBM

未测试这些产品，无法确认与非 IBM 产品相关的性能、兼容性或其他任何声明的准确性。有关非 IBM

产品功能的问题应提交给这些产品的提供商。

关于 IBM 未来发展方向或打算的声明仅代表 IBM 的发展目标，如有变更或撤销，恕不另行通知。

本信息包含日常业务操作中使用的数据和报告的示例。为了尽可能完整地演示它们，示例中提供了一

些个人、公司、品牌和产品的名称。所有这些名称均是虚构的，如与实际商业企业使用的名称和地址

有任何雷同，纯属巧合。

版权许可：© 版权所有 IBM Corporation 2012。保留所有权利。

本信息包含源语言形式的示例应用程序，演示了在各种操作平台上的编程技术。为了开发、使用、推广

或分发符合操作平台应用编程接口（样例程序正是为之而编写）的应用程序，您可以以任何形式复制、

修改和分发这些样例程序，无需向 IBM 付费。这些示例未在所有条件下进行全面测试。因此，IBM 不能

保证或暗示这些程序的可靠性、可服务性或功能。

商标 IBM、IBM 徽标和 ibm.com 是国际商业机器公司在美国和/或其他国家/地区的商标或注册商标。如

果这些和其他 IBM 商标词汇在本信息中首次出现时标注了商标符号（® 或 ™），这些符号表示 IBM

在本信息发布之际在美国的注册商标或普通法规定的商标。这些商标也可能是其他国家/地区的注册

商标或约定俗成的商标。可在网络上获取 IBM 商标的最新列表，请查看

www.ibm.com/legal/copytrade.shtml 上的“Copyright and trademark information”部

分。

Windows是 Microsoft Corporation 在美国和/或其他国家/地区的商标。

UNIX 是 The Open Group 在美国和其他国家/地区的注册商标。

Linux 是 Linus Torvalds 在美国和/或其他国家/地区的注册商标。

其他公司、产品或服务名称可能是其他公司的商标或服务标志。

db2 galileo query performance enhancements...db2 version 10.1 查询性能改进 第 5 页（共 18...

Documents

db2 galileo query performance enhancements...db2 version 10.1 查询性能改进第 5 页（共 18...