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 效率。