第一次和第二次的执行计划为啥不一样
下面的sql执行了两次，发现两次的执行计划有不一致的地方。recursive calls（递归调用）第一次是284，第二次是0。consistent gets（一致性读），第一次是88，第二次是2。为什么？问了下c哥，第一次执行sql的时候，需要硬解析sql代码。第二次执行的时候share pool area已经存在执行计划，直接拿来用即可。这些知识在书里都看过，但还是需要实际操作才印象深刻啊。以后审核sql脚本的执行计划，需要执行2次。第一次是硬解析，第二次才真正是在share pool area共享池的消耗。

SQL> set autotrace traceonly
SQL> set timing on
SQL> select * from openapi_company_info where companyid=1;

已用时间:  00: 00: 00.01

Execution Plan
----------------------
   0      SELECT STATEMENT ptimizer=ALL_ROWS (Cost=1 Card=1 Bytes=374)

   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'OPENAPI_COMPANY_INFO' (TABLE) (Cost=1 Card=1 Bytes=374)

   2    1     INDEX (UNIQUE SCAN) OF 'OPENAPI_COMPANY_INFO_PK' (INDEX(UNIQUE)) (Cost=0 Card=1)

Statistics
----------------------
        284  recursive calls
          0  db block gets
         88  consistent gets
          0  physical reads
          0  redo size
       2378  bytes sent via SQL*Net to client
        496  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
          1  rows processed




SQL> select * from openapi_company_info where companyid=1;

已用时间:  00: 00: 00.01

Execution Plan
----------------------
   0      SELECT STATEMENT ptimizer=ALL_ROWS (Cost=1 Card=1 Bytes=374)

   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'OPENAPI_COMPANY_INFO' (TABLE) (Cost=1 Card=1 Bytes=374)

   2    1     INDEX (UNIQUE SCAN) OF 'OPENAPI_COMPANY_INFO_PK' (INDEX(UNIQUE)) (Cost=0 Card=1)
Statistics
----------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
       2378  bytes sent via SQL*Net to client
        496  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed