COUNT()函数的性能有关问题

2013-08-04

COUNT()函数的性能问题table表中有不止一列select count（*） from table和select count（id） from table有什

COUNT()函数的性能问题
table表中有不止一列
select count（*） from table
和
select count（id） from table
有什么性能差别吗
第二种是否会好一些呢？
[解决办法]
1) count（*）统计所有行、很难走索引、或者走索引代价极大、CBO不会走
2）count（id）统计 id 不为空的行、如果id列有索引、就可以走索引

综上、在满足业务的情况下、第二种好、
[解决办法]
看效率最最好以查询计划为主，上面两个语句如果仅是统计表的行数，大多数情况下效率是一样的
SQL> select count(*) from emp;

  COUNT(*)
----------
        14

执行计划
----------------------
Plan hash value: 2937609675

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

[解决办法]
Id
[解决办法]
Operation
[解决办法]
Name
[解决办法]
Rows
[解决办法]
Cost (%CPU)
[解决办法]
Time
[解决办法]

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

[解决办法]
   0
[解决办法]
SELECT STATEMENT
[解决办法]

[解决办法]
     1
[解决办法]
     1   (0)

[解决办法]
00:00:01
[解决办法]

[解决办法]
   1
[解决办法]
  SORT AGGREGATE
[解决办法]

[解决办法]
     1
[解决办法]

[解决办法]

[解决办法]

[解决办法]
   2
[解决办法]
   INDEX FULL SCAN
[解决办法]
PK_EMP
[解决办法]
    14
[解决办法]
     1   (0)
[解决办法]
00:00:01
[解决办法]

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

SQL> select count(empno) from emp;

COUNT(EMPNO)
------------
          14

执行计划
----------------------
Plan hash value: 2937609675

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

[解决办法]
Id
[解决办法]
Operation
[解决办法]
Name
------解决方案--------------------

Rows
[解决办法]
Cost (%CPU)
[解决办法]
Time
[解决办法]

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

[解决办法]
   0
[解决办法]
SELECT STATEMENT
[解决办法]

[解决办法]
     1
[解决办法]
     1   (0)
[解决办法]
00:00:01
[解决办法]

[解决办法]
   1
[解决办法]
  SORT AGGREGATE
[解决办法]

[解决办法]
     1
[解决办法]

[解决办法]

[解决办法]

[解决办法]
   2
[解决办法]
   INDEX FULL SCAN
[解决办法]
PK_EMP
[解决办法]
    14
[解决办法]
     1   (0)

[解决办法]
00:00:01
[解决办法]

-------------------------------
[解决办法]

引用:

1) count（*）统计所有行、很难走索引、或者走索引代价极大、CBO不会走
2）count（id）统计 id 不为空的行、如果id列有索引、就可以走索引

综上、在满足业务的情况下、第二种好、

1)count(*) 优化器会判断是否可以走索引的，如果含有主键或非空索引，那么计划就会走索引
2）如果ID列不是通常的B索引，或者该列就没有索引，那么count(ID）为统计非空和空的行总数
SQL> select count(*) from
  2  (select null from dual union all
  3  select 1 from dual) t;

  COUNT(*)
----------
         2
[解决办法]

引用:

Quote: 引用:

Quote: 引用:

1) count（*）统计所有行、很难走索引、或者走索引代价极大、CBO不会走
2）count（id）统计 id 不为空的行、如果id列有索引、就可以走索引

综上、在满足业务的情况下、第二种好、

1)count(*) 优化器会判断是否可以走索引的，如果含有主键或非空索引，那么计划就会走索引
2）如果ID列不是通常的B索引，或者该列就没有索引，那么count(ID）为统计非空和空的行总数
SQL> select count(*) from
  2  (select null from dual union all
  3  select 1 from dual) t;

  COUNT(*)
----------
         2

1）count(*) 优化器会判断是否可以走索引的是的、会判断、CBO会对所有可能的路线都进行判断、然后选择其中成本最低的那条去走、如果含有主键或非空索引，那么计划就会走索引你所认为的含主键走索引、也是把索引当"瘦表"来回答一个查询、至于"非空索引"这个我有点不太理解？非空？b树索引不能存空值吧

2）count(ID）为统计非空和空的行总数即便不存在索引、你都认为count(id)统计总行数吗？如果是这样、我不是很赞同、

1) "非空索引” 我说的可能不太清楚，我指的是非空约束的索引列
SQL> create table t(id int not null,nn varchar2(50));

表已创建。

SQL> create index idx_id on t(id);

索引已创建。
2）至于这个问题，您可以举个反例，这样大家能更好的明白

热点排行

Bad Request.

oracle

COUNT()函数的性能有关问题