一、 前言

在调查一个性能问题的时候，一个同事问道，为什么数据库有些时候这么不聪明，明明表上有索引，但是在执行一个简单的count的时候居然全表扫描了！难道不知道走索引更快么？

试图从最简单的count来重新了解oracle查询计划的选择，以及最终产生的结果。虽然有些结果会让人觉得有些意外，并且可能会鄙视，这个查询 计划选择真的不够聪明。但稍微用心点的去了解，做的已经足够细致了。大多数情况下，根据我们输入的信息，来自输入的SQL、表结构、索引状况、统计信息， 会得出一个比较优的计划。所以和前面一直试图讲到索引和join方式一样，所有这样的选择不是因为数据库厂商这样规定的，而是基于存储的数据的实际情况， 就应该(甚至说不得不)这么去选择。

二、实验条件

-- Create table

createtableIDOUBA.APP_APPLICATIONAUDIT

(

  ID              NUMBER,

  UNIQUEID        NUMBER,

  POLICYID        NUMBER,

  IP              VARCHAR2(200)notnull,

  IPNUM           NUMBERnotnull,

  MAC             VARCHAR2(200),

  USERVISIT       VARCHAR2(100),

  PHONE           VARCHAR2(200),

  GROUPNAME       VARCHAR2(100),

  PORT            NUMBER,

  APP_URL         VARCHAR2(200),

  TITLE           VARCHAR2(200),

  REQUESTS        VARCHAR2(1000),

  REQIDENTITYCARDVARCHAR2(1000),

  REQKEY      VARCHAR2(1000),

  RESPONSEEKEY     VARCHAR2(3000),

  UPDATETIME      DATE,

  AUDITTYPE       NUMBER,

  TITLEID         NUMBER,

  SUBTITLEID      NUMBER,

  SERVERIP        VARCHAR2(200),

  DOMAINNAME      VARCHAR2(200)

)

tablespaceUSERS

  pctfree10

  initrans1

  maxtrans255

  storage

  (

    initial64K

    minextents1

    maxextentsunlimited

  );

-- Create/Recreate indexes

createindexINDEX_UPDATETIMEonIDOUBA.APP_APPLICATIONAUDIT(UPDATETIME)

  tablespaceSYSTEM

  pctfree10

  initrans2

  maxtrans255

  storage

  (

    initial64K

    minextents1

    maxextentsunlimited

  );

表中有20001000条记录，有二十多个字段，包括几个长度比较大的字段。为了实验测试，只是讲IP字段设置为not null。在UpdateTime上建了默认的B树索引。

三、输入

分为三种场景来讨论，然后比较其结果，然后分析该结果。说明数据库的执行计划的选择其实是足够聪明的。

场景一：

  • 表结构：只是在有一个可以为null的列UpdateTime上建了一个索引
  • SQL：最简单的Count。
selectcount(*)fromIDOUBA.App_ApplicationAudit;      --count(*)

selectcount(PolicyId)fromIDOUBA.App_ApplicationAudit;      --count(可以null的列)

selectcount(IP)fromIDOUBA.App_ApplicationAudit;      --count(不可null的列)

selectcount(UpdateTime)fromIDOUBA.App_ApplicationAudit;  --count(可以为null并且建了索引的列)

场景二：

  • 表结构：和场景一完全相同，只是在有一个可以为null的列UpdateTime上建了一个索引
  • SQL：多了个Where子句，在Where子句中涉及到建了索引的可以为null的列。
selectcount(*)fromIDOUBA.App_ApplicationAuditwhereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');      --count(*)

selectcount(PolicyId)fromIDOUBA.App_ApplicationAuditwhereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');    --count(可以null的列)

selectcount(IP)fromIDOUBA.App_ApplicationAuditwhereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');      --count(不可null的列)

selectcount(UpdateTime)fromyIDOUBA.App_ApplicationAuditwhereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');  --count(可以为null并且建了索引的列)

场景三：

  • 表结构：除了有一个可以为null的列UpdateTime上建了一个索引外，设置另外一列IpNum列为not null，并且在其上创建索引。
  • SQL：最简单的Count。
selectcount(*)fromIDOUBA.App_ApplicationAudit;      --count(*)

selectcount(PolicyId)fromIDOUBA.App_ApplicationAudit;      --count(可以null的列)

selectcount(IP)fromIDOUBA.App_ApplicationAudit;      --count(不可null的列)

selectcount(UpdateTime)fromIDOUBA.App_ApplicationAudit;  --count(可以为null并且建了索引的列)

四、实验结果

场景/Count类型 Count(*) Count(PolicyId) 非索引可null的列 Count(IP)非索引not null 的列 Count(Updatetime)可以null的索引列 Count(IPNum) not null 的索引列
执行时间(秒) 物理读 执行操作 执行时间(秒) 物理读 执行操作 执行时间(秒) 物理读 执行操作 执行时间(秒) 物理读 执行操作 执行时间(秒) 物理读 physical reads 执行操作
场景一 50.98 51671 表扫描 47.43 451672 表扫描 47.73 451672 表扫描 8.7 82393 UpdateTime上快速索引扫描 无 无 无
场景二 9.28 82395 UpdateTime上快速索引扫描 48.12 451673 表扫描 9.65 82428 UpdateTime上快速索引扫描 9.03 82394 UpdateTime上快速索引扫描 无 无 无
场景三 5.14 50224 IpNum上快速索引扫描 47.89 451672 表扫描 2.25 15153 IpNum上快速索引扫描 9.06 82393 UpdateTime上快速索引扫描 3.2 82393 IpNum上快速索引扫描

五、结果分析

其实观察查询计划，也就两种，一种快速索引扫描(INDEX FAST FULL SCAN)，另外一种是全表扫描（TABLE ACCESS FULL|）。因为实验表中数据量还是不算小，有两千多万，两者的对比还是比较明显。主要体现在总的执行时间，和物理读取上面，差着一个量级。下面对表中 的执行结果逐个进行总结和解释。

场景一：

当表中只在一个可以null的列上建索引的情况下。观察到count(*) 、count not null的列count(IP)，count 可以null的列PolicyId的count(PolicyId)的效果一样都是走全表扫描（TABLE ACCESS FULL|）；而对于count建了索引并且列可以null的列count(UpdateTime)，走快速索引扫描(INDEX FAST FULL SCAN)。即只在索引列UpdateTime上， count会走快速索引扫描(INDEX FAST FULL SCAN)，其他都是全表扫描。

解释：因为oracle不会索引null，因此扫描该列上的索引只能知道该列上非null的值，而count(*) 和count(非空列)都是统计总行数，从索引上不能获得该信息，只能全表扫描。而count(可空列)就更不能参照该索引了，建了索引的可空列上非 null的行数，和在count的可空列上非null的行数没有任何关系，因此也只能全表扫描了。

场景二：

比场景一where子句中包含了可以null的列update的条件where updatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’) 。观察到count(*)和count not null的列count(IP)和count UpdateTime一样都走updatetime上的快速索引扫描(INDEX FAST FULL SCAN)；而count 可null列PolicyId的count(PolicyId)还是全表扫描。

解释：满足类似于pdatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’)这样可空列上的条件，其实隐含的意思是满足该条件并且该列上取值不为null的行的行数。则在这列上的 count，count(*)，在其他非null列上的count，表达的都是这个意思，因此可以利用该索引来做索引扫描。而在另外一个可null的列上 的count是表示满足该where条件同时在count列上值非null的记录行数，索引列上不为空的行可能在该列上为空，因此不能参照那个索引，只能 全表扫描。

场景三：

当表中存在一个not null的列IpNum上建了索引。观察到count(*)和count（IP）在非空索引上快速索引扫描(INDEX FAST FULL SCAN)，但是count(ProjectId)还是走原来的全表扫描。即：当表上在一个not null列上建了索引，则只有可Null的列的count走全表扫描，其他的都会走这个建了索引的no null 列的快速索引扫描(INDEX FAST FULL SCAN)。

解释：有一个not null的列上建了索引，则这个索引上的记录数就是表的行数，count(*),count(非空列)都是数行数。但是count(可null 列)是数这个列上不为空的记录数，因此不能参照索引，只能全表扫描了。

六、总结

在Oracle中，Count(Column)是计算Column上不为该列取值不为null的行数，Count一个not null的列其实就是总行数。而Count(*)是不区分null或者not null就是所有记录行数。因此二者语义是一样的，实验也证明了在各种情况下其执行计划总是一样的。对于这两种Count，表上无论哪个索引能提供这样的 语义（在例子中场景二和场景三的两个不同索引分别提供了这样的语义），就会走这个索引。如果没有索引能提供这个语义，就不得不走全表扫描了。而Count 一个可以为null的列，因为要数本列上到底有多少行的值不为null，因此不能参照别的列，必须在该列上数数，如果该列上有索引，则会在该列的索引上扫 描，如果该列上没有索引，则不得不全表扫描。

七、附：各种场景的执行计划

1. 只是在有一个可以为null的列UpdateTime上建了一个索引的Count(*)

SQL>selectcount(*)fromIDOUBA.App_ApplicationAudit;

  COUNT(*)

----------

  20001000

已用时间:  00:00:50.98

执行计划

----------------------------------------------------------

Planhashvalue:2649150711

-----------------------------------------------------------------------------------

|Id  |Operation          |Name                 |Rows  |Cost(%CPU)|Time     |

-----------------------------------------------------------------------------------

|   0|SELECTSTATEMENT   |                      |     1|99985   (2)|00:20:00|

|   1|  SORTAGGREGATE    |                      |     1|            |          |

|   2|   TABLEACCESSFULL|APP_APPLICATIONAUDIT|    19M|99985   (2)|00:20:00|

-----------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

        166  recursivecalls

          0  dbblockgets

     451721  consistentgets

     451671  physicalreads

          0  redosize

        410  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

2. 只是在有一个可以为null的列UpdateTime上建了一个索引的Count一个可以null的列policyId

SQL>selectcount(policyId)fromIDOUBA.App_ApplicationAudit;

COUNT(POLICYID)

---------------

       20001000

已用时间:  00:00:47.43

执行计划

----------------------------------------------------------

Planhashvalue:2649150711

-------------------------------------------------------------------------------------------

|Id  |Operation          |Name                 |Rows  |Bytes|Cost(%CPU)|Time     |

-------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT   |                      |     1|     2|   100K  (2)|00:20:02|

|   1|  SORTAGGREGATE    |                      |     1|     2|            |          |

|   2|   TABLEACCESSFULL|APP_APPLICATIONAUDIT|    19M|    38M|   100K  (2)|00:20:02|

-------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

          1  recursivecalls

          0  dbblockgets

     451701  consistentgets

     451672  physicalreads

          0  redosize

        417  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          0  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

3. 只是在有一个可以为null的列UpdateTime上建了一个索引的Count一个可以null的索引列updatetime：Count(UpdateTime)

SQL>selectcount(updatetime)fromIDOUBA.App_ApplicationAudit;

COUNT(UPDATETIME)

-----------------

         20001000

已用时间:  00:00:08.70

执行计划

----------------------------------------------------------

Planhashvalue:3909306724

------------------------------------------------------------------------------------------

|Id  |Operation             |Name             |Rows  |Bytes|Cost(%CPU)|Time     |

------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |                  |     1|     8|18204   (3)|00:03:39|

|   1|  SORTAGGREGATE       |                  |     1|     8|            |          |

|   2|   INDEXFASTFULLSCAN|INDEX_UPDATETIME|    19M|   152M|18204   (3)|00:03:39|

------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

        164  recursivecalls

          0  dbblockgets

      82448  consistentgets

      82393  physicalreads

          0  redosize

        419  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

4. 只是在有一个可以为null的列UpdateTime上建了一个索引的Count一个not null的非索引列IP：Count(IP)

SQL>selectcount(Ip)fromIDOUBA.App_ApplicationAudit;

COUNT(IP)

----------

  20001000

已用时间:  00:00:47.73

执行计划

----------------------------------------------------------

Planhashvalue:2649150711

-----------------------------------------------------------------------------------

|Id  |Operation          |Name                 |Rows  |Cost(%CPU)|Time     |

-----------------------------------------------------------------------------------

|   0|SELECTSTATEMENT   |                      |     1|99985   (2)|00:20:00|

|   1|  SORTAGGREGATE    |                      |     1|            |          |

|   2|   TABLEACCESSFULL|APP_APPLICATIONAUDIT|    19M|99985   (2)|00:20:00|

-----------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

        218  recursivecalls

          0  dbblockgets

     451730  consistentgets

     451672  physicalreads

          0  redosize

        411  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

5. 只是在有一个可以为null的列UpdateTime上建了一个索引，Query的Where子句中包含该UpdateTime列的条件where updatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’) ，Count(*)

SQL>selectcount(*)fromIDOUBA.App_ApplicationAudit  whereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');

  COUNT(*)

----------

  20001000

已用时间:  00:00:09.28

执行计划

----------------------------------------------------------

Planhashvalue:3909306724

------------------------------------------------------------------------------------------

|Id  |Operation             |Name             |Rows  |Bytes|Cost(%CPU)|Time     |

------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |                  |     1|     8|18373   (4)|00:03:41|

|   1|  SORTAGGREGATE       |                  |     1|     8|            |          |

|*  2|   INDEXFASTFULLSCAN|INDEX_UPDATETIME|    19M|   152M|18373   (4)|00:03:41|

------------------------------------------------------------------------------------------

PredicateInformation(identifiedbyoperationid):

---------------------------------------------------

   2-filter("UPDATETIME">TO_DATE('2013-05-01 10:23:44','yyyy-mm-dd

              hh24:mi:ss'))

统计信息

----------------------------------------------------------

        227  recursivecalls

          0  dbblockgets

      82464  consistentgets

      82395  physicalreads

          0  redosize

        410  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

6. 只是在有一个可以为null的列UpdateTime上建了一个索引，Query的Where子句中包含该UpdateTime列的条件where updatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’) 。Count一个可以null的列PolicyId：Count(PolicyId)

SQL>selectcount(policyId)fromIDOUBA.App_ApplicationAudit  whereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');

COUNT(POLICYID)

---------------

       20001000

已用时间:  00:00:48.12

执行计划

----------------------------------------------------------

Planhashvalue:2649150711

-------------------------------------------------------------------------------------------

|Id  |Operation          |Name                 |Rows  |Bytes|Cost(%CPU)|Time     |

-------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT   |                      |     1|    10|   101K  (3)|00:20:20|

|   1|  SORTAGGREGATE    |                      |     1|    10|            |          |

|*  2|   TABLEACCESSFULL|APP_APPLICATIONAUDIT|    19M|   190M|   101K  (3)|00:20:20|

-------------------------------------------------------------------------------------------

PredicateInformation(identifiedbyoperationid):

---------------------------------------------------

   2-filter("UPDATETIME">TO_DATE('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss'))

统计信息

----------------------------------------------------------

        227  recursivecalls

          0  dbblockgets

     451737  consistentgets

     451673  physicalreads

          0  redosize

        417  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

7. 只是在有一个可以为null的列UpdateTime上建了一个索引，Query的Where子句中包含该UpdateTime列的条件where updatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’) 。Count一个not null的列IP：Count(IP)

SQL>selectcount(ip)fromIDOUBA.App_ApplicationAudit  whereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');

COUNT(IP)

----------

  20001000

已用时间:  00:00:09.65

执行计划

----------------------------------------------------------

Planhashvalue:3909306724

------------------------------------------------------------------------------------------

|Id  |Operation             |Name             |Rows  |Bytes|Cost(%CPU)|Time     |

------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |                  |     1|     8|18373   (4)|00:03:41|

|   1|  SORTAGGREGATE       |                  |     1|     8|            |          |

|*  2|   INDEXFASTFULLSCAN|INDEX_UPDATETIME|    19M|   152M|18373   (4)|00:03:41|

------------------------------------------------------------------------------------------

PredicateInformation(identifiedbyoperationid):

---------------------------------------------------

   2-filter("UPDATETIME">TO_DATE('2013-05-01 10:23:44','yyyy-mm-dd

              hh24:mi:ss'))

统计信息

----------------------------------------------------------

          1  recursivecalls

          0  dbblockgets

      82428  consistentgets

      82393  physicalreads

          0  redosize

        411  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          0  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

8. 只是在有一个可以为null的列UpdateTime上建了一个索引，Query的Where子句中包含该UpdateTime列的条件where updatetime > to_date(’2013-05-01 10:23:44′, ‘yyyy-mm-dd hh24:mi:ss’) 。Count该可以 null的索引列UpdateTime：Count(UpdateTime)

SQL>selectcount(updatetime)fromIDOUBA.App_ApplicationAuditwhereupdatetime>to_date('2013-05-01 10:23:44','yyyy-mm-dd hh24:mi:ss');

COUNT(UPDATETIME)

-----------------

         20001000

已用时间:  00:00:09.03

执行计划

----------------------------------------------------------

Planhashvalue:3909306724

------------------------------------------------------------------------------------------

|Id  |Operation             |Name             |Rows  |Bytes|Cost(%CPU)|Time     |

------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |                  |     1|     8|18204   (3)|00:03:39|

|   1|  SORTAGGREGATE       |                  |     1|     8|            |          |

|   2|   INDEXFASTFULLSCAN|INDEX_UPDATETIME|    19M|   152M|18204   (3)|00:03:39|

------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

        185  recursivecalls

          0  dbblockgets

      82460  consistentgets

      82394  physicalreads

          0  redosize

        419  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

          1  rowsprocessed

9. 在一个not null的列IPNum创建索引count（*）

SQL>selectcount(*)fromIDOUBA.App_ApplicationAudit;

  COUNT(*)

----------

  20001000

已用时间:  00:00:05.14

执行计划

----------------------------------------------------------

Planhashvalue:2581539037

-----------------------------------------------------------------------------

|Id  |Operation             |Name        |Rows  |Cost(%CPU)|Time     |

-----------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |             |     1|11435   (5)|00:02:18|

|   1|  SORTAGGREGATE       |             |     1|            |          |

|   2|   INDEXFASTFULLSCAN|INDEX_IPNUM|    19M|11435   (5)|00:02:18|

-----------------------------------------------------------------------------

统计信息

----------------------------------------------------------

          1  recursivecalls

          0  dbblockgets

      50253  consistentgets

      50224  physicalreads

          0  redosize

        410  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          0  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

10 在一个not null的列IPNum创建索引。Count可null的列PolicyId：Count(PolicyId)

SQL>selectcount(policyId)fromIDOUBA.App_ApplicationAudit;

COUNT(POLICYID)

---------------

       20001000

已用时间:  00:00:47.89

执行计划

----------------------------------------------------------

Planhashvalue:2649150711

-------------------------------------------------------------------------------------------

|Id  |Operation          |Name                 |Rows  |Bytes|Cost(%CPU)|Time     |

-------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT   |                      |     1|     2|   100K  (2)|00:20:02|

|   1|  SORTAGGREGATE    |                      |     1|     2|            |          |

|   2|   TABLEACCESSFULL|APP_APPLICATIONAUDIT|    19M|    38M|   100K  (2)|00:20:02|

-------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

          1  recursivecalls

          0  dbblockgets

     451701  consistentgets

     451672  physicalreads

          0  redosize

        417  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          0  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

11 在一个not null的列IPNum创建索引。Count not null的列IP：Count(IP)

SQL>selectcount(Ip)fromIDOUBA.App_ApplicationAudit;

COUNT(IP)

----------

  20001000

已用时间:  00:00:02.25

执行计划

----------------------------------------------------------

Planhashvalue:2581539037

-----------------------------------------------------------------------------

|Id  |Operation             |Name        |Rows  |Cost(%CPU)|Time     |

-----------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |             |     1|11435   (5)|00:02:18|

|   1|  SORTAGGREGATE       |             |     1|            |          |

|   2|   INDEXFASTFULLSCAN|INDEX_IPNUM|    19M|11435   (5)|00:02:18|

-----------------------------------------------------------------------------

统计信息

----------------------------------------------------------

        196  recursivecalls

          0  dbblockgets

      50290  consistentgets

      15153  physicalreads

          0  redosize

        411  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          5  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

12 在一个not null的列IPNum创建索引。Count另外一个建了索引的可null的列UpdateTime：Count(UpdateTime)

SQL>selectcount(updatetime)fromIDOUBA.App_ApplicationAudit;

COUNT(UPDATETIME)

-----------------

         20001000

已用时间:  00:00:09.06

执行计划

----------------------------------------------------------

Planhashvalue:3909306724

------------------------------------------------------------------------------------------

|Id  |Operation             |Name             |Rows  |Bytes|Cost(%CPU)|Time     |

------------------------------------------------------------------------------------------

|   0|SELECTSTATEMENT      |                  |     1|     8|18204   (3)|00:03:39|

|   1|  SORTAGGREGATE       |                  |     1|     8|            |          |

|   2|   INDEXFASTFULLSCAN|INDEX_UPDATETIME|    19M|   152M|18204   (3)|00:03:39|

------------------------------------------------------------------------------------------

统计信息

----------------------------------------------------------

          1  recursivecalls

          0  dbblockgets

      82428  consistentgets

      82393  physicalreads

          0  redosize

        419  bytessentviaSQL*Nettoclient

        385  bytesreceivedviaSQL*Netfromclient

          2  SQL*Netroundtripsto/fromclient

          0  sorts(memory)

          0  sorts(disk)

1    rowsprocessed

完。

原创文章。为了维护文章的版本一致、最新、可追溯，转载请注明： 转载自idouba

本文链接地址: 从Count看Oracle执行计划的选择

从Count看Oracle执行计划的选择的更多相关文章

  1. 看懂Oracle执行计划

    最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的略有所知,也来总结一下自己最近所学,不定时更新ing- 一:什么是Oracle执行计划? 执行计划是一条查询语句在Oracle中的执行过程或访问 ...

  2. [转]看懂Oracle执行计划

    原文地址:https://www.cnblogs.com/Dreamer-1/p/6076440.html 一:什么是Oracle执行计划? 执行计划是一条查询语句在Oracle中的执行过程或访问路径 ...

  3. 看懂Oracle执行计划、表连接方式

    看懂Oracle执行计划  原文:https://www.cnblogs.com/Dreamer-1/p/6076440.html 最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的略有所知,也 ...

  4. 02 看懂Oracle执行计划

    看懂Oracle执行计划   最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的略有所知,也来总结一下自己最近所学,不定时更新ing… 一:什么是Oracle执行计划? 执行计划是一条查询语句在 ...

  5. 如何看懂ORACLE执行计划

    如何看懂Oracle执行计划 一.什么是执行计划 An explain plan is a representation of the access path that is taken when a ...

  6. Oracle调优之看懂Oracle执行计划

    @ 目录 1.文章写作前言简介 2.什么是执行计划? 3.怎么查看执行计划? 4.查看真实执行计划 5.看懂Oracle执行计划 5.1 查看explain 5.2 explain执行顺序 5.3 访 ...

  7. （Oracle）看懂Oracle执行计划（转载）

    最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的略有所知,也来总结一下自己最近所学,不定时更新ing- 一:什么是Oracle执行计划? 执行计划是一条查询语句在Oracle中的执行过程或访问 ...

  8. Oracle执行计划 explain plan

    Rowid的概念:rowid是一个伪列,既然是伪列,那么这个列就不是用户定义,而是系统自己给加上的. 对每个表都有一个rowid的伪列,但是表中并不物理存储ROWID列的值.不过你可以像使用其它列那样 ...

  9. Oracle执行计划不走索引的原因总结

    在Oracle数据库操作中,为什么有时一个表的某个字段明明有索引,当观察一些语的执行计划确不走索引呢?如何解决呢?本文我们主要就介绍这部分内容,接下来就让我们一起来了解一下. 不走索引大体有以下几个原 ...

随机推荐

  1. 关于为什么java需要垃圾回收

    为什么java采用垃圾回收而c++却不采用,这是因为在java中,所有对象变量都是引用,当一个引用被新对象覆盖掉时,就没有引用指向原来的对象了,这个对象就“失控了”. 而C++中,除非使用特殊符号&a ...

  2. (一)CSS三种插入方式

    CSS概述 CSS(Cascading Style Sheets)指层叠样式表,样式定义了如何显示HTML元素. 样式通常存储在样式表中,样式与HTML分离解决了内容与表现分离的问题. 多个样式表可以 ...

  3. 【HDOJ】4801 Pocket Cube 的几种解法和优化

    1. 题目描述给定一个$2 \times 2 \times 2$的魔方,当某个面上的4个小块颜色均相同时,称这个面为complete.求对这个魔方进行$n \in [1,7]$次旋转(沿某个面顺时针或 ...

  4. linux中压缩与解压缩命令小结

    linux中压缩与解压操作非常常见,其命令参数也非常的多,这里只介绍最经常用的带打包文件的几种压缩和解压方式和几个最常用的参数. 现在最常用的压缩和解压工具是gzip和bzip2,这两种工具不能相互解 ...

  5. Android手机拍照

    参考的这个视频教程:http://v.youku.com/v_show/id_XNjI5MzkzMjQ4.html和官方API档file:///D:/Android/androidstudio/sdk ...

  6. （任寒韬）WebApp群主 - MobileTech 资料

    web app : http://www.lightapp.cn/brand/index/4101 https://github.com/jtyjty99999/mobileTech/blob/mas ...

  7. 编译pure-ftpd时提示错误Your MySQL client libraries aren't properly installed

    如果出现类似configure: error: Your MySQL client libraries aren’t properly installed 的错误,请将mysql目录下的 includ ...

  8. Android平台程序崩溃的类型及原因列举

    Android平台程序崩溃大家都应该遇到过,force close和ANR应该是大家遇到较多的. 这里把Android平台程序崩溃的各种类型做一个简述和原因列举. 1.ANR(可见ANR): 发生场景 ...

  9. 消息提示和消息推送插件toastr

    http://www.jq22.com/yanshi476 比较棒的消息提示和消息推送插件toastr function myIntervalshow() { // showPopup1(300, 1 ...

  10. Android aidl 打入jar解决方法

    工程上右键 选择export 然后取消选择这个工程里的所有的文件 点开到gen文件夹下选择aidl生成的 java文件 选择生成的java文件和src目录导出jar包即可