SQL 语句优化贯穿于数据库类应用程序的整个生命周期，包括前期程序开发，产品测试以及后期生产维护。针对于不同类型的 SQL 性能问题有不同的优化方法。索引对于改善数据库 SQL 查询操作性能至关重要，如何选择合适的列以及正确的组合所选择的列创建索引对查询语句的性能有着极大的影响，本文将结合具体案例进行解释。

问题描述

客户 A 业务核心数据库采用 DB2 UDB，业务部门报告其中一个模块响应缓慢，通过分析该业务模块代码可以定位为一条性能较差的 SQL 语句。

清单 1. 影响性能的 SQL 语句
1
2
3
db2fox@bivm:~/test> cat t1.sql
select name,location,address from t1 where name=16123
db2fox@bivm:~/test>

问题分析与解决

步骤一：分析该 SQL 语句的执行计划

DB2 提供了能分析 SQL 执行计划的工具:db2expln，通过分析 SQL 执行计划我们将了解 DB2 优化器选择了什么样的“途径”来访问数据，执行计划的优劣将直接影响 SQL 的性能。

清单 2. 执行计划输出结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
db2fox@bivm:~/test> db2expln -database fox -i -g -stmtfile t1.sql -terminator ';' -output t1.exp
db2fox@bivm:~/test> cat t1.exp
DB2 Universal Database Version 10.5, 5622-044 (c) Copyright IBM Corp. 1991, 2012
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
******************** DYNAMIC ***************************************
==================== STATEMENT ==========================================
    Isolation Level = Cursor Stability
    Blocking = Block Unambiguous Cursors
    Query Optimization Class = 5
    Partition Parallel = No
    Intra-Partition Parallel = No
    SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM",
 "DB2FOX"
Statement:
 select name, location, address
 from t1
 where name=16123
Section Code Page = 1208
Estimated Cost = 3517.214111 --此处我们可以看到行计划的 COST 值
Estimated Cardinality = 3600.000000
( 2) Access Table Name = DB2FOX.T1 ID = 4,513
 | #Columns = 3
 | Skip Inserted Rows
 | Avoid Locking Committed Data
 | Currently Committed for Cursor Stability
 | May participate in Scan Sharing structures
 | Scan may start anywhere and wrap, for completion
 | Fast scan, for purposes of scan sharing management
 | Scan can be throttled in scan sharing management
 | Relation Scan
 | | Prefetch: Eligible
 | Lock Intents
 | | Table: Intent Share
 | | Row : Next Key Share
 | Sargable Predicate(s)
 | | #Predicates = 1
( 1) | | Return Data to Application
 | | | #Columns = 3
( 1) Return Data Completion
End of section
Optimizer Plan:
 Rows
 Operator
 (ID)
 Cost
 3600
 RETURN
 ( 1)
 3517.21
 |
 3600
 TBSCAN --> 该执行计划选择了全表扫描
 ( 2)
 3517.21
 |
 90000
 Table:
 DB2FOX
 T1

这是一条非常简单的 SQL 语句，其执行计划选择了“全表扫描”，一般情况下全表扫描的“代价”较高而执行效率较差，相对而言，使用索引的效率要高的多，但在一些特殊情况下“全表扫描”的效率要优于“使用索引”，影响优化器选择的因素有很多，包括：表的大小，查询结果集的大小，有无索引，I/O 预读等。

清单 3. 表的统计信息
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
db2fox@bivm:~/test> db2 "select count(*) from t1"
1
-----------
 90000
 1 record(s) selected.
fox@bivm:~/test> db2 "select substr(indname,1,10),substr(tabname,1,20),
substr(colnames,1,20) from syscat.indexes where tabname='T1'"
1 2 3
---------- -------------------- --------------------
I_T1 T1 +LOCATION+NAME
db2fox@bivm:~/test> db2 "select firstkeycard, first2keycard from syscat.indexes
> where indname='I_T1'"
FIRSTKEYCARD FIRST2KEYCARD
-------------------- ---------------------------------------------------
 3 -->重复值非常的多59093 -->重复值非常的少
 1 record(s) selected.
db2fox@bivm:~/test>
db2fox@bivm:~/test> db2 "describe table t1"
 Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
NAME SYSIBM CHARACTER 40 0 Yes
LOCATION SYSIBM CHARACTER 50 0 Yes
ADDRESS SYSIBM VARCHAR 130 0 Yes
 3 record(s) selected.
db2fox@bivm:~/test>

T1 表上有一个名为“I_T1”的索引，该表有大概 9 万条记录，而且 NAME 列的重复值非常的少，这种情况下影响业务性能的 SQL 语句非常适合使用索引，但当前的执行计划却选择了“全表扫描”！我们再仔细观察一下该 SQL 语句的原文：select name,location,address from t1 where name=16123 请注意 where 条件 name=16123 这是一个“数值”类型，而 t1 表中 NAME 列定义的是“字符”类型的，这可能是影响执行化选择的原因！

步骤二：修改 SQL 原文

将 SQL 原文中 where 条件部分加“引号”以使得“优化器”可以选择索引。

清单 4. 重新生成执行计划，验证优化效果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
db2fox@bivm:~/test> cat t1.sql
select name,location,address from t1 where name='16123'
db2fox@bivm:~/test>
db2fox@bivm:~/test> db2expln -database fox -i -g -stmtfile t1.sql -terminator ';' -output t1.exp
DB2 Universal Database Version 10.5, 5622-044 (c) Copyright IBM Corp. 1991, 2012
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
Output is available in "t1.exp".
db2fox@bivm:~/test> cat t1.exp
DB2 Universal Database Version 10.5, 5622-044 (c) Copyright IBM Corp. 1991, 2012
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
******************** DYNAMIC ***************************************
==================== STATEMENT ==========================================
    Isolation Level = Cursor Stability
    Blocking = Block Unambiguous Cursors
    Query Optimization Class = 5
    Partition Parallel = No
    Intra-Partition Parallel = No
    SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM",
 "DB2FOX"
Statement:
 select name, location, address
 from t1
 where name='16123'
Section Code Page = 1208
Estimated Cost = 132.665771 -->COST 值比优化前改善非常明显
Estimated Cardinality = 2.596810
( 2) Access Table Name = DB2FOX.T1 ID = 4,513
 | Index Scan: Name = DB2FOX.I_T1 ID = 1
 | | Regular Index (Not Clustered)
 | | Index Columns:
 | | | 1: LOCATION (Ascending)
 | | | 2: NAME (Ascending)
 | #Columns = 2
 | Skip Inserted Rows
 | Avoid Locking Committed Data
 | Currently Committed for Cursor Stability
 | Evaluate Predicates Before Locking for Key
 | #Key Columns = 2
 | | Start Key: Inclusive Value
 | | | 1: [GAP Unconstrained]
 | | | 2: '16123 ...'
 | | Stop Key: Inclusive Value
 | | | 1: [GAP Unconstrained]
 | | | 2: '16123 ...'
 | Data Prefetch: Sequential(2), Readahead
 | Index Prefetch: Sequential(4), Readahead
 | Lock Intents
 | | Table: Intent Share
 | | Row : Next Key Share
 | Sargable Predicate(s)
( 1) | | Return Data to Application
 | | | #Columns = 3
( 1) Return Data Completion
End of section
Optimizer Plan:
 Rows
 Operator
 (ID)
 Cost
 2.59681
 RETURN
 ( 1)
 132.666
 |
 2.59681
 FETCH
 ( 2)
 132.666
 / \
 2.59681 90000
 IXSCAN Table:
 ( 3) DB2FOX
 115.093 T1
 |
 59093
 Index:
 DB2FOX -->已经使用了索引
 I_T1
db2fox@bivm:~/test>

重新执行该 SQL 语句验证其优化效果，可以看出该 SQL 已经有明显的改善，但依然没有满足业务期望。SQL 的性能很大程度上是与“索引”相关的, 正确的使用索引以及合理的设计“索引”是改善 SQL 性能的最主要手段，“索引”质量的高低也将直接影响 SQL 的性能好坏。

步骤三：分析相关索引

索引 I_T1 是由 LOCATION 列和 NAME 列联合构成的“组合索引”，通常情况下“组合索引”的“引导列”（排在最左边的列）对查询语句中的 where 条件影响最大，而索引 I_T1 的引导列为 LOCATION, 因此可以考虑新创建一个索引只有 NAME 列或者创建一个新的由 NAME 列为引导列的组合索引。

清单 5. 创建以 NAME 列为引导列的索引
1
2
3
4
5
6
7
8
9
db2fox@bivm:~> db2 "create index i_t1_name on t1(name)"
DB20000I The SQL command completed successfully.
db2fox@bivm:~> db2 "describe indexes for table t1"
Index Index Unique Number of Index Index Null
schema name rule columns type partitioning keys
------------------------------- ------------------- --------------
DB2FOX I_T1 D 2 RELATIONAL DATA - Y
DB2FOX I_T1_NAME  D 1 RELATIONAL DATA - Y
 2 record(s) selected.
清单 6. 重新生成执行计划，验证优化效果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
db2fox@bivm:~/test> db2expln -database fox -i -g -stmtfile t1.sql -terminator ';' -output t1.exp
DB2 Universal Database Version 10.5, 5622-044 (c) Copyright IBM Corp. 1991, 2012
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
Output is available in "t1.exp".
db2fox@bivm:~/test> cat t1.exp
DB2 Universal Database Version 10.5, 5622-044 (c) Copyright IBM Corp. 1991, 2012
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
******************** DYNAMIC ***************************************
==================== STATEMENT ==========================================
    Isolation Level = Cursor Stability
    Blocking = Block Unambiguous Cursors
    Query Optimization Class = 5
    Partition Parallel = No
    Intra-Partition Parallel = No
    SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM",
 "DB2FOX"
Statement:
 select name, location, address
 from t1
 where name='16123'
Section Code Page = 1208
Estimated Cost = 27.005688 -->COST 值比优化前改善非常明显
Estimated Cardinality = 2.898831
( 2) Access Table Name = DB2FOX.T1 ID = 4,513
 | Index Scan: Name = DB2FOX.I_T1_NAME ID = 2
 | | Regular Index (Not Clustered)
 | | Index Columns:
 | | | 1: NAME (Ascending)
 | #Columns = 2
 | Skip Inserted Rows
 | Avoid Locking Committed Data
 | Currently Committed for Cursor Stability
 | Evaluate Predicates Before Locking for Key
 | #Key Columns = 1
 | | Start Key: Inclusive Value
 | | | 1: '16123 ...'
 | | Stop Key: Inclusive Value
 | | | 1: '16123 ...'
 | Data Prefetch: Sequential(1), Readahead
 | Index Prefetch: Sequential(1), Readahead
 | Lock Intents
 | | Table: Intent Share
 | | Row : Next Key Share
 | Sargable Predicate(s)
( 1) | | Return Data to Application
 | | | #Columns = 3
( 1) Return Data Completion
End of section
Optimizer Plan:
 Rows
 Operator
 (ID)
 Cost
 2.89883
 RETURN
 ( 1)
 27.0057
 |
 2.89883
 FETCH
 ( 2)
 27.0057
 / \
 2.89883 90000
 IXSCAN Table:
 ( 3) DB2FOX
 13.5494 T1
 |
 30731
 Index:
 DB2FOX
 I_T1_NAME -->优化器选择新创建的索引
db2fox@bivm:~/test>

从以上的执行计划中可以看到 COST 值从最初的3517.214111最终降低到27.005688，该 SQL 语句的性能提升非常明显。

索引设计原则

索引通常用于加速对表的访问。但是，逻辑数据设计也可以使用索引。例如，唯一索引不允许列中存在重复值的条目，从而保证了一个表中不会有两行相同的记录。还可以创建索引，以将一列中的值按升序或降序进行排序。

要点： 在创建索引时要记住，虽然它们可以提高查询性能，但会对写性能产生负面影响。出现此负面影响是因为对于数据库管理器写入表中的每行，它还必须更新任何受影响的索引。因此，只有在能够明显提高整体性能时，才应创建索引。

在创建索引时，还应考虑表结构和最常对这些表执行查询的类型。例如，频繁发出的查询的 WHERE 子句中出现的列很适合作为索引。但是，在较少运行的查询中，索引对 INSERT 和 UPDATE 语句的性能产生的负面影响可能超过所带来的好处。

同样，在经常运行的查询的 GROUP BY 子句中出现的列可能会从创建索引中获益，尤其在用于分组行的值的数目小于要分组的行数时。

在创建索引时, 也可以进行压缩。之后，您可以使用 ALTER INDEX 语句来修改索引，从而启用或禁用压缩功能。

要删除索引，可以使用 DROP INDEX 命令。

设计索引时的准则和注意事项

  1. 虽然构成一个索引键的列的顺序不会影响索引键的创建，但是当它决定是否使用索引时就可能影响优化器。例如，如果查询包含 ORDER BY col1,col2 子句，那么可以使用对 (col1,col2) 创建的索引，但对 (col2,col1) 创建的索引没什么帮助。同样，如果查询指定了条件，例如 where col1 >= 50 and col1 <= 100 或 where col1=74，那么对 (col1) 或 (col1,col2) 创建的索引将起作用，但基于 (col2,col1) 的索引的作用不大。
  2. 可以对特定的表定义任意数目的索引（最大数目为 32767），这些索引能提高查询性能。
  3. 索引管理器必须在更新、删除和插入操作期间维护索引。为有很多更新内容的表创建大量索引可能减慢请求的处理速度。同样，大型索引键也会减慢处理请求的速度。因此，仅当频繁访问明显有利之时，才使用索引。
  4. 不是唯一索引键的一部分但要在该索引中存储或维护的列数据称为包含列。只能为唯一索引指定包含列。当用包含列创建索引时，仅对唯一键列进行排序并考虑其唯一性。使用包含列可以启用仅访问索引来进行数据检索，从而提高性能。
  5. 如果要建立索引的表是空的，那么仍会创建索引，但是在装入该表或插入行之前，不会建立任何索引条目。如果该表不为空，那么数据库管理器将在处理 CREATE INDEX 语句时创建索引条目。
  6. 索引会消耗磁盘空间。该磁盘空间大小取决于键列的长度和要建立索引的行数。随着插入到表中的数据增多，索引大小也会增加。因此，在规划数据库大小时，应考虑正在建立索引的数据量。

注： 都应该按重复值最少到重复值最多的顺序对索引键中的列进行排序。此排序提供最佳性能。

结束语

本案例中通过修改了两 SQL 原文并重新设计了一个索引达到了优化目的，满足了业务要求，当数据库出现性能问题时，通过现象分析其本质，最终找到优化的具体方法。数据库优化是一个系统化的过程，有时无法一蹴而就，需要循序渐进。深刻的理解数据库的运行机制和原理是迅速判断性能问题的基础。

参考：https://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1511-db2sql-optmize/

db2 执行计划的更多相关文章

  1. db2执行计划介绍

    在数据库调优过程中,SQL语句往往是导致性能问题的主要原因,而执行计划则是解释SQL语句执行过程的语言,只有充分读懂执行计划才能在数据库性能优化中做到游刃有余. 常见的关系型数据库中,虽然执行计划的表 ...

  2. db2执行计划具体操作

    explain 1.如果第一次执行,请先(在dbinst用户下) connect to dbname,执行db2 -tvf $HOME/sqllib/misc/EXPLAIN.DDL建立执行计划表 2 ...

  3. DB2执行计划分析

    多表连接的三种方式详解 hash join.merge join. nested loop 项目中的SQL执行效率太低,就用执行计划看一下执行SQL,看不懂,百度一下,纪录下来: 大多数人从来没有听说 ...

  4. db2数据库创建索引，删除索引，查看表索引，SQL语句执行计划以及优化建议

    1.建立表索引 create index 索引名 on 表名(列名,列名); 2.删除表索引 drop index 索引名 on 表名; 3.查看表索引 select * from sysibm.sy ...

  5. DB2命令行查看执行计划

    查看对应SQL的执行计划 分析程序包   db2expln -d 数据库名 -i -g -c 模式名-p程序包 -s 0 -t   db2expln -d 数据库名 -i -g -c 模式名-p程序包 ...

  6. 使用Hint来优化执行计划

    最近看主管优化了一个HINT相关的查询 借此机会学习下HINT 参考Notes: Note 129385 - Database hints in Open SQL http://www.stechno ...

  7. DB查询分析器7.01新增的周、月SQL执行计划功能

                DB查询分析器7.01新增的周.月SQL执行计划功能 马根峰              (广东联合电子服务股份有限公司, 广州 510300) 1      引言   中国本土 ...

  8. mysql系列八、mysql数据库优化、慢查询优化、执行计划分析

    mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面进行优化,最终性能就会有大的提升. 一.介绍 对mysql优化是一个综合性的技术,主要包括 表的设计合理化(符合3NF) 添加适当索引( ...

  9. (转)explain、db2exfmt 命令的使用：文本输出执行计划

    原文:http://blog.51cto.com/freebile/1068610 db2有图形执行计划显示工具,如果没有图形环境,如unix主机,可以生成文本的文件来显示执行计划1.如果第一次执行, ...

随机推荐

  1. [模板][P4782]2-SAT

    Description: 有n个布尔变量\(x_1\)~\(x_n\),另有m个需要满足的条件,每个条件的形式都是"\(x_i\)为true/false或\(x_j\)为true/false ...

  2. BZOJ3736 : [Pa2013]Karty

    显然只需要考虑与障碍点相邻的格子,通过旋转坐标系,可以只考虑障碍点在格子上方的情况. 悬线法求出每个点往上的最长延伸距离$x$,以及往左往右的延伸距离$y$. 那么当$r\geq x$时,$c$至多为 ...

  3. python系统编程（九）

    同步的概念 1. 多线程开发可能遇到的问题 假设两个线程t1和t2都要对num=0进行增1运算,t1和t2都各对num修改10次,num的最终的结果应该为20. 但是由于是多线程访问,有可能出现下面情 ...

  4. ZKW线段树入门

    Part 1 来说说它的构造 线段树的堆式储存 我们来转成二进制看看 小学生问题:找规律 规律是很显然的 一个节点的父节点是这个数左移1,这个位运算就是低位舍弃,所有数字左移一位 一个节点的子节点是这 ...

  5. Perfect Service [POJ 3398]

    Perfect Service 描述 网络由N个通过N-1个通信链路连接的计算机组成,使得任何两台计算机可以通过独特的路由进行通信.如果两台计算机之间存在通信链路,则称这两台计算机是相邻的.计算机的邻 ...

  6. 用shell脚本守护后台进程

    假如现在在 crond 中添加了一个每分钟执行的定时任务如下: */ * * * * root cd /data/sbin; sh test.sh >/dev/>& 为了防止上一个 ...

  7. 【枚举】Consonant Fencity @upcexam5110

    时间限制: 3 Sec 内存限制: 512 MB 题目描述 There are two kinds of sounds in spoken languages: vowels and consonan ...

  8. delphi TTBXToolBar 增加外部控件

    这样可以引用外部控件,还是比较方便

  9. mount: wrong fs type, bad option, bad superblock

    mount: wrong fs type, bad option, bad superblock on 125.64.41.244:/data/img,       missing codepage ...

  10. Jetpack 迁移到 androidX support MD

    Markdown版本笔记 我的GitHub首页 我的博客 我的微信 我的邮箱 MyAndroidBlogs baiqiantao baiqiantao bqt20094 baiqiantao@sina ...