一个有关ｃｏｕｎｔ的试验．

oldwain

这样做:

在sqlpus下:

scott@O817> @connect scott/tiger@o817
已连接。
scott@O817> alter session set timed_statistics=true;

会话已更改。

scott@O817> alter session set sql_trace = true;

会话已更改。

scott@O817> select count(*) from tab;

  COUNT(*)
----------
        54

scott@O817> alter session set sql_trace=false;

会话已更改。

scott@O817> alter session set timed_statistics=false;

会话已更改。

scott@O817>


然后, 在dos提示符下, 到oracle_hom\admin\sid\udump\
找到最新的trc文件(示例中味ora00607.trc).
执行:
C:\Oracle\ADMIN\O817\udump>tkprof ora00607.trc mytest.out
然后, 用文本编辑器打开mytest.out即可.

alan_yang

I had known the way to get  the trace file by the command tkprof

in linux. And the following is the result of my test
(It is ran in my  test database):

A.  the result show in sqlplus:

Welcome> set timing on
Welcome> alter session set sql_trace=true
  2  /

Session altered.

Elapsed: 00:00:00.00
Welcome> select count(*) from test,test
  2  /
  60109009

Elapsed: 00:00:37.45
Welcome> select count(1) from test,test
  2  /
  60109009

Elapsed: 00:00:51.93

B. The result show in trace_file:
select count(*)
from
test,test


call        count       cpu    elapsed       disk      query    current        rows
--------         -----      --------     ----------    ----------    ----------     ----------      ----------
Parse          1        0.00        0.00            0            0             0              0
Execute      1        0.00        0.00            0            0             0              0
Fetch          2        0.00        0.00            0    54278     31016              1
-------        ------       --------     ----------    ----------    ----------     ----------      ----------
total            4        0.00        0.00            0     54278     31016             1

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 39
Rows     Row Source Operation
-------  ---------------------------------------------------
1  SORT AGGREGATE
60109009   NESTED LOOPS
7754    TABLE ACCESS FULL TEST
60109009    TABLE ACCESS FULL TEST
********************************************************************************

select count(1)
from
test,test


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0      54278      31016           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0      54278      31016           1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 39

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE
60109009   NESTED LOOPS
   7754    TABLE ACCESS FULL TEST
60109009    TABLE ACCESS FULL TEST

奇怪，从ｓｑｌｐｌｕｓ中的显示来看，时间有差别，而且
ｃｏｕｎｔ（＊）比ｃｏｕｎｔ（１）更快．而从ｔｒａｃｅ
文件中看来两者所花费的代价却是一样的．这这么解释好呢？

ｏｌｄｗａｉｎ，说说看吧．

oldwain

对这个问题, 我以前也是非常较真的.

可是后来看到asktom的那篇帖子, 我开始觉得真的没有多大的意义了.

正像tom说的, count(1), count(*) 从原理来讲, 绝对是一样的;

但是, 不同的数据, 不同的环境, 得出的结论不完全相同(甚至不完全相同).
换句话说, 你用一个实例得到的结论并不能适用于另一个实例或另一个环境.

在这种情况下, 讨论还能有什么意义?

alan_yang

看来再讨论下去也是白费时间的，

没必要在这样的细节上花费太多功夫．

其实就我几次测试来看，结果不尽相同

但总体来说差别不是很大．

cactus

RT

oldwain

sum与count不同.
sum没有那么多替代方案. 你应该sum哪个列, 就只能sum哪个列.
所以没有什么客讨论的.

backlove

你的打假行动完成了吗？xixi

cactus

这个例中出现空的数据是否参加运算？
所有数据均不为空，和有部分数据为空，哪个速度快？
BTW：前提条件是，记录数相等