1 如果要分析某条SQL的性能问题，通常我们要先看SQL的执行计划，看看SQL的每一步执行是否存在问题。 如果一条SQL平时执行的好好的，却有一天突然性能很差，如果排除了系统资源和阻塞的原因，那么基本可以断定是执行计划出了问题。
2
3
4
5 看懂执行计划也就成了SQL优化的先决条件。 这里的SQL优化指的是SQL性能问题的定位，定位后就可以解决问题。
6
7
8
9
10
11 一． 查看执行计划的三种方法
12
13 1.1 设置autotrace
14
15 序号
16
17 命令
18
19 解释
20
21 1
22
23 SET AUTOTRACE OFF
24
25 此为默认值，即关闭Autotrace
26
27 2
28
29 SET AUTOTRACE ON EXPLAIN
30
31 只显示执行计划
32
33 3
34
35 SET AUTOTRACE ON STATISTICS
36
37 只显示执行的统计信息
38
39 4
40
41 SET AUTOTRACE ON
42
43 包含2,3两项内容
44
45 5
46
47 SET AUTOTRACE TRACEONLY
48
49 与ON相似，但不显示语句的执行结果
50
51
52
53 SQL> set autotrace on
54
55 SQL> select * from dave;
56
57 ID NAME
58
59 ---------- ----------
60
61 8 安庆
62
63 1 dave
64
65 2 bl
66
67 1 bl
68
69 2 dave
70
71 3 dba
72
73 4 sf-express
74
75 5 dmm
76
77
78
79 已选择8行。
80
81
82
83 执行计划
84
85 ----------------------------------------------------------
86
87 Plan hash value: 3458767806
88
89 --------------------------------------------------------------------------
90
91 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
92
93 --------------------------------------------------------------------------
94
95 | 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
96
97 | 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
98
99 --------------------------------------------------------------------------
100
101
102
103 统计信息
104
105 ----------------------------------------------------------
106
107 0 recursive calls
108
109 0 db block gets
110
111 4 consistent gets
112
113 0 physical reads
114
115 0 redo size
116
117 609 bytes sent via SQL*Net to client
118
119 416 bytes received via SQL*Net from client
120
121 2 SQL*Net roundtrips to/from client
122
123 0 sorts (memory)
124
125 0 sorts (disk)
126
127 8 rows processed
128
129
130
131 SQL>
132
133
134
135 1.2 使用SQL
136
137 SQL>EXPLAIN PLAN FOR sql语句;
138
139 SQL>SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
140
141
142
143 示例：
144
145 SQL> EXPLAIN PLAN FOR SELECT * FROM DAVE;
146
147 已解释。
148
149 SQL> SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
150
151 或者：
152
153 SQL> select * from table(dbms_xplan.display);
154
155 PLAN_TABLE_OUTPUT
156
157 --------------------------------------------------------------------------------
158
159 Plan hash value: 3458767806
160
161
162
163 --------------------------------------------------------------------------
164
165 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
166
167 --------------------------------------------------------------------------
168
169 | 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
170
171 | 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
172
173 --------------------------------------------------------------------------
174
175 已选择8行。
176
177 执行计划
178
179 ----------------------------------------------------------
180
181 Plan hash value: 2137789089
182
183 --------------------------------------------------------------------------------
184
185 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
186
187 ---------------------------------------------------------------------------------------------
188
189 | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
190
191 | 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
192
193 ---------------------------------------------------------------------------------------------
194
195
196
197 统计信息
198
199 ----------------------------------------------------------
200
201 25 recursive calls
202
203 12 db block gets
204
205 168 consistent gets
206
207 0 physical reads
208
209 0 redo size
210
211 974 bytes sent via SQL*Net to client
212
213 416 bytes received via SQL*Net from client
214
215 2 SQL*Net roundtrips to/from client
216
217 1 sorts (memory)
218
219 0 sorts (disk)
220
221 8 rows processed
222
223 SQL>
224
225
226
227 1.3 使用Toad,PL/SQL Developer工具
228
229
230
231
232
233 二． Cardinality（基数）/ rows
234
235 Cardinality值表示CBO预期从一个行源（row source）返回的记录数，这个行源可能是一个表，一个索引，也可能是一个子查询。 在Oracle 9i中的执行计划中，Cardinality缩写成Card。 在10g中，Card值被rows替换。
236
237
238
239 这是9i的一个执行计划，我们可以看到关键字Card：
240
241 执行计划
242
243 ----------------------------------------------------------
244
245 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=402)
246
247 1 0 TABLE ACCESS (FULL) OF 'TBILLLOG8' (Cost=2 Card=1 Bytes=402)
248
249
250
251 Oracle 10g的执行计划，关键字换成了rows：
252
253 执行计划
254
255 ----------------------------------------------------------
256
257 Plan hash value: 2137789089
258
259 --------------------------------------------------------------------------------
260
261 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
262
263 ---------------------------------------------------------------------------------------------
264
265 | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
266
267 | 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
268
269 ---------------------------------------------------------------------------------------------
270
271
272
273 Cardinality的值对于CBO做出正确的执行计划来说至关重要。 如果CBO获得的Cardinality值不够准确（通常是没有做分析或者分析数据过旧造成），在执行计划成本计算上就会出现偏差，从而导致CBO错误的制定出执行计划。
274
275
276
277 在多表关联查询或者SQL中有子查询时，每个关联表或子查询的Cardinality的值对主查询的影响都非常大，甚至可以说，CBO就是依赖于各个关联表或者子查询Cardinality值计算出最后的执行计划。
278
279
280
281 对于多表查询，CBO使用每个关联表返回的行数（Cardinality）决定用什么样的访问方式来做表关联（如Nested loops Join 或 hash Join）。
282
283 多表连接的三种方式详解 HASH JOIN MERGE JOIN NESTED LOOP
284
285 http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5826546.aspx
286
287
288
289 对于子查询，它的Cardinality将决定子查询是使用索引还是使用全表扫描的方式访问数据。
290
291
292
293
294
295
296
297 三． SQL 的执行计划
298
299 生成SQL的执行计划是Oracle在对SQL做硬解析时的一个非常重要的步骤，它制定出一个方案告诉Oracle在执行这条SQL时以什么样的方式访问数据：索引还是全表扫描，是Hash Join还是Nested loops Join等。 比如说某条SQL通过使用索引的方式访问数据是最节省资源的，结果CBO作出的执行计划是全表扫描，那么这条SQL的性能必然是比较差的。
300
301 Oracle SQL的硬解析和软解析
302
303 http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5458896.aspx
304
305
306
307 示例：
308
309 SQL> SET AUTOTRACE TRACEONLY; -- 只显示执行计划，不显示结果集
310
311 SQL> select * from scott.emp a,scott.emp b where a.empno=b.mgr;
312
313 已选择13行。
314
315
316
317 执行计划
318
319 ----------------------------------------------------------
320
321 Plan hash value: 992080948
322
323 ---------------------------------------------------------------------------------------
324
325 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
326
327 ---------------------------------------------------------------------------------------
328
329 | 0 | SELECT STATEMENT | | 13 | 988 | 6 (17)| 00:00:01 |
330
331 | 1 | MERGE JOIN | | 13 | 988 | 6 (17)| 00:00:01 |
332
333 | 2 | TABLE ACCESS BY INDEX ROWID| EMP | 14 | 532 | 2 (0)| 00:00:01 |
334
335 | 3 | INDEX FULL SCAN | PK_EMP | 14 | | 1 (0)| 00:00:01 |
336
337 |* 4 | SORT JOIN | | 13 | 494 | 4 (25)| 00:00:01 |
338
339 |* 5 | TABLE ACCESS FULL | EMP | 13 | 494 | 3 (0)| 00:00:01 |
340
341 ---------------------------------------------------------------------------------------
342
343
344
345 Predicate Information (identified by operation id):
346
347 ---------------------------------------------------
348
349 4 - access("A"."EMPNO"="B"."MGR")
350
351 filter("A"."EMPNO"="B"."MGR")
352
353 5 - filter("B"."MGR" IS NOT NULL)
354
355
356
357 统计信息
358
359 ----------------------------------------------------------
360
361 0 recursive calls
362
363 0 db block gets
364
365 11 consistent gets
366
367 0 physical reads
368
369 0 redo size
370
371 2091 bytes sent via SQL*Net to client
372
373 416 bytes received via SQL*Net from client
374
375 2 SQL*Net roundtrips to/from client
376
377 1 sorts (memory)
378
379 0 sorts (disk)
380
381 13 rows processed
382
383 SQL>
384
385
386
387
388
389
390
391
392
393 图片是Toad工具查看的执行计划。 在Toad 里面，很清楚的显示了执行的顺序。 但是如果在SQLPLUS里面就不是那么直接。 但我们也可以判断：一般按缩进长度来判断，缩进最大的最先执行，如果有2行缩进一样，那么就先执行上面的。
394
395
396
397
398
399 3.1 执行计划中字段解释：
400
401 ID: 一个序号，但不是执行的先后顺序。执行的先后根据缩进来判断。
402
403 Operation： 当前操作的内容。
404
405 Rows： 当前操作的Cardinality，Oracle估计当前操作的返回结果集。
406
407 Cost（CPU）：Oracle 计算出来的一个数值（代价），用于说明SQL执行的代价。
408
409 Time：Oracle 估计当前操作的时间。
410
411
412
413 3.2 谓词说明：
414
415 Predicate Information (identified by operation id):
416
417 ---------------------------------------------------
418
419 4 - access("A"."EMPNO"="B"."MGR")
420
421 filter("A"."EMPNO"="B"."MGR")
422
423 5 - filter("B"."MGR" IS NOT NULL)
424
425
426
427 Access: 表示这个谓词条件的值将会影响数据的访问路劲（表还是索引）。
428
429 Filter：表示谓词条件的值不会影响数据的访问路劲，只起过滤的作用。
430
431
432
433 在谓词中主要注意access，要考虑谓词的条件，使用的访问路径是否正确。
434
435
436
437
438
439 3.3 统计信息说明：
440
441
442
443
444
445
446
447 db block gets ： 从buffer cache中读取的block的数量
448
449 consistent gets： 从buffer cache中读取的undo数据的block的数量
450
451 physical reads： 从磁盘读取的block的数量
452
453 redo size： DML生成的redo的大小
454
455 sorts (memory) ：在内存执行的排序量
456
457 sorts (disk) ：在磁盘上执行的排序量
458
459
460
461 Physical Reads通常是我们最关心的，如果这个值很高，说明要从磁盘请求大量的数据到Buffer Cache里，通常意味着系统里存在大量全表扫描的SQL语句，这会影响到数据库的性能，因此尽量避免语句做全表扫描，对于全表扫描的SQL语句，建议增 加相关的索引，优化SQL语句来解决。
462
463
464
465 关于physical reads ，db block gets 和consistent gets这三个参数之间有一个换算公式：
466
467 数据缓冲区的使用命中率=1 - ( physical reads / (db block gets + consistent gets) )。
468
469
470
471 用以下语句可以查看数据缓冲区的命中率：
472
473 SQL>SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
474
475 查询出来的结果Buffer Cache的命中率应该在90％以上，否则需要增加数据缓冲区的大小。
476
477
478
479 Recursive Calls： Number of recursive calls generated at both the user and system level.
480
481 Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call. In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL—all incur recursive SQL calls。
482
483
484
485 DB Block Gets： Number of times a CURRENT block was requested.
486
487 Current mode blocks are retrieved as they exist right now, not in a consistent read fashion. Normally, blocks retrieved for a query are retrieved as they existed when the query began. Current mode blocks are retrieved as they exist right now, not from a previous point in time. During a SELECT, you might see current mode retrievals due to reading the data dictionary to find the extent information for a table to do a full scan (because you need the "right now" information, not the consistent read). During a modification, you will access the blocks in current mode in order to write to them. (DB Block Gets:请求的数据块在buffer能满足的个数)
488 当前模式块意思就是在操作中正好提取的块数目，而不是在一致性读的情况下而产生的块数。正常的情况下，一个查询提取的块是在查询开始的那个时间点上存在的数据块，当前块是在这个时刻存在的数据块，而不是在这个时间点之前或者之后的数据块数目。
489
490
491
492 Consistent Gets： Number of times a consistent read was requested for a block.
493
494 This is how many blocks you processed in "consistent read" mode. This will include counts of blocks read from the rollback segment in order to roll back a block. This is the mode you read blocks in with a SELECT, for example. Also, when you do a searched UPDATE/DELETE, you read the blocks in consistent read mode and then get the block in current mode to actually do the modification. (Consistent Gets: 数据请求总数在回滚段Buffer中的数据一致性读所需要的数据块)
495 这里的概念是在处理你这个操作的时候需要在一致性读状态上处理多少个块，这些块产生的主要原因是因为由于在你查询的过程中，由于其他会话对数据块进行操 作，而对所要查询的块有了修改，但是由于我们的查询是在这些修改之前调用的，所以需要对回滚段中的数据块的前映像进行查询，以保证数据的一致性。这样就产 生了一致性读。
496
497
498
499 Physical Reads： Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache. (Physical Reads:实例启动后，从磁盘读到Buffer Cache数据块数量)
500
501 就是从磁盘上读取数据块的数量，其产生的主要原因是：
502 （1） 在数据库高速缓存中不存在这些块
503 （2） 全表扫描
504 （3） 磁盘排序
505 它们三者之间的关系大致可概括为：
506 逻辑读指的是Oracle从内存读到的数据块数量。一般来说是'consistent gets' + 'db block gets'。当在内存中找不到所需的数据块的话就需要从磁盘中获取，于是就产生了'physical reads'。
507
508
509
510 Sorts(disk):
511
512 Number of sort operations that required at least one disk write. Sorts that require I/O to disk are quite resource intensive. Try increasing the size of the initialization parameter SORT_AREA_SIZE.
513
514
515
516 bytes sent via SQL*Net to client:
517 Total number of bytes sent to the client from the foreground processes.
518
519
520
521 bytes received via SQL*Net from client:
522 Total number of bytes received from the client over Oracle Net.
523
524
525
526 SQL*Net roundtrips to/from client:
527 Total number of Oracle Net messages sent to and received from the client.
528
529
530
531
532
533
534
535
536
537 更多内容参考Oracle联机文档：
538
539 Statistics Descriptions
540
541 http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/stats002.htm#i375475
542
543
544
545
546
547 3.4 动态分析
548
549 如果在执行计划中有如下提示：
550
551 Note
552
553 ------------
554
555 -dynamic sampling used for the statement
556
557
558
559 这提示用户CBO当前使用的技术，需要用户在分析计划时考虑到这些因素。 当出现这个提示，说明当前表使用了动态采样。 我们从而推断这个表可能没有做过分析。
560
561
562
563
564
565 这里会出现两种情况：
566
567 （1） 如果表没有做过分析，那么CBO可以通过动态采样的方式来获取分析数据，也可以或者正确的执行计划。
568
569 （2） 如果表分析过，但是分析信息过旧，这时CBO就不会在使用动态采样，而是使用这些旧的分析数据，从而可能导致错误的执行计划。
570
571
572
573
574
575
576
577 总结：
578
579 在看执行计划的时候，除了看执行计划本身，还需要看谓词和提示信息。 通过整体信息来判断SQL 效率。
浙公网安备 33010602011771号