Oracle里count(1)、count(*)和count(主键)哪个更快

前端之家收集整理的这篇文章主要介绍了Oracle里count(1)、count(*)和count(主键)哪个更快前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

这两天听了将近20场演讲,感觉收获很多,最深的感觉就是自己还有很长的路要走。有几个点记录一下:

昨天听老猫讲,提到一个普遍的问题就是Oracle里count(*)、count(1)和count(主键)到底哪个快的问题。这个问题看起来很简单,每个人都会有自己的答案,去百度上搜会出来一大堆帖子来讲哪个更快。但是老猫说了它们三个其实是一样的,我听到之后也觉得挺诧异的,因为我记得别人跟我说过count(主键)会快,然后自己简单想了一下,觉得好像是那么回事的就没有深入去追究。接着老猫说官方有这样的说法这三个其实是等价的。晚上回来之后到MOS上查了一下,居然被我找到了How the Oracle CBO Chooses a Path for the SELECT COUNT(*) Command (文档 ID 124717.1)。这篇文档讲的就是在CBO优化器模式下,Oracle怎样去评估没有where条件select count(*)和select count(colum)语句的最优路径。

1、创建测试表并设计测试场景:

--创建测试表
sys@ORCL>createtablejournal_entries
2(id_jenumber(8),3date_jedatenotnull,4balancednumber,5constraintindx_ecr_id_jeprimarykey(id_je)
6);

Tablecreated.
--创建索引
sys@ORCL>createindexindx_ecr_date_je_balancedonjournal_entries(date_je,balanced);

Indexcreated.

sys@ORCL>createindexindx_ecr_balanced_date_jeonjournal_entries(balanced,date_je);

Indexcreated.

sys@ORCL>createindexindx_ecr_balancedonjournal_entries(balanced);

Indexcreated.
--插入测试数据
sys@ORCL>insertintojournal_entriesvalues(1,sysdate,11);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(2,21);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(3,31);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(4,41);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(5,51);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(6,61);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(7,71);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(8,81);

1rowcreated.

sys@ORCL>insertintojournal_entriesvalues(9,91);

1rowcreated.

sys@ORCL>commit;

Commitcomplete.
--收集统计信息
sys@ORCL>execdbms_stats.gather_table_stats(ownname=>USER,tabname=>'JOURNAL_ENTRIES',cascade=>true);

PL/sqlproceduresuccessfullycompleted.

设计四个场景进行对比:

Sel1 : Select count(*) from journal_entries;
Sel2 : Select count(1) from journal_entries;
Sel3 : Select count(id_je) from journal_entries;

Sel4 : Select count(balanced) from journal_entries;

1、场景1和场景2等价

For CBO,Sel1 and Sel2 are strictly equivalent

sys@ORCL>altersessionsetstatistics_level=all;

Sessionaltered.

sys@ORCL>selectcount(*)fromjournal_entries;

COUNT(*)
----------
9

sys@ORCL>select*fromtable(dbms_xplan.display_cursor(null,null,'runstats_last'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
sql_ID5ja3ukp4wd73p,childnumber0
-------------------------------------
selectcount(*)fromjournal_entries

Planhashvalue:42135099

---------------------------------------------------------------------------------------------
|Id|Operation|Name|Starts|E-Rows|A-Rows|A-Time|Buffers|
---------------------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1||1|00:00:00.01|1|
|1|SORTAGGREGATE||1|1|1|00:00:00.01|1|
|2|INDEXFULLSCAN|INDX_ECR_ID_JE|1|9|9|00:00:00.01|1|
---------------------------------------------------------------------------------------------


14rowsselected.

sys@ORCL>selectcount(1)fromjournal_entries;

COUNT(1)
----------
9

sys@ORCL>select*fromtable(dbms_xplan.display_cursor(null,'runstats_last'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
sql_IDgbxjjuqj9j7ww,childnumber0
-------------------------------------
selectcount(1)fromjournal_entries

Planhashvalue:42135099

---------------------------------------------------------------------------------------------
|Id|Operation|Name|Starts|E-Rows|A-Rows|A-Time|Buffers|
---------------------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1||1|00:00:00.01|1|
|1|SORTAGGREGATE||1|1|1|00:00:00.01|1|
|2|INDEXFULLSCAN|INDX_ECR_ID_JE|1|9|9|00:00:00.01|1|
---------------------------------------------------------------------------------------------


14rowsselected.

可以看到两个语句的执行计划是完全相同的。

2、场景3也与前两个场景等价,因为id_je有NOT NULL约束

For Sel3,CBO does the same as for Sel1 and Sel2 since "id_je" has aNOT NULL constraint.

sys@ORCL>selectcount(id_je)fromjournal_entries;

COUNT(ID_JE)
------------
9

sys@ORCL>select*fromtable(dbms_xplan.display_cursor(null,'runstats_last'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
sql_IDb1p4v15dwx7hs,childnumber0
-------------------------------------
selectcount(id_je)fromjournal_entries

Planhashvalue:42135099

---------------------------------------------------------------------------------------------
|Id|Operation|Name|Starts|E-Rows|A-Rows|A-Time|Buffers|
---------------------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1||1|00:00:00.01|1|
|1|SORTAGGREGATE||1|1|1|00:00:00.01|1|
|2|INDEXFULLSCAN|INDX_ECR_ID_JE|1|9|9|00:00:00.01|1|
---------------------------------------------------------------------------------------------


14rowsselected.

可以看到执行计划与前两个也是完全相同的。

4、场景4跟前边3个不同,因为balanced列上没有NOT NULL约束,但是balanced列上有索引,那会走这个列上的索引么?我们来看一下执行计划:

sys@ORCL>selectcount(balanced)fromjournal_entries;

COUNT(BALANCED)
---------------
9

sys@ORCL>select*fromtable(dbms_xplan.display_cursor(null,'runstats_last'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
sql_IDbc3bc8c0fg14z,childnumber0
-------------------------------------
selectcount(balanced)fromjournal_entries

Planhashvalue:3638043346

--------------------------------------------------------------------------------------------------------
|Id|Operation|Name|Starts|E-Rows|A-Rows|A-Time|Buffers|
--------------------------------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1||1|00:00:00.01|1|
|1|SORTAGGREGATE||1|1|1|00:00:00.01|1|
|2|INDEXFULLSCAN|INDX_ECR_DATE_JE_BALANCED|1|9|9|00:00:00.01|1|
--------------------------------------------------------------------------------------------------------


14rowsselected.

我们看到这个执行计划没有走balanced列上的索引,而是走了和date_je的联合索引。这个可以查看另一篇文档:Note:67522.1 Why is my index not used?

小结一下:

我这里只是简单的从执行计划上看count(*)、count(1)和count(主键)其实是一致,MOS的文档中详细的讲解了Oracle是如何评估执行计划的,也可以使用10053 event查看CBO优化器是如何做出选择的。由于我的功力还不够,对于10053事件还不是很明白,暂时就先不做演示了,要不哪说错了就不好了,这也可以做为以后博客分享内容

从这个事情上来看,我们对于一件事情应该做一个深入的研究,有充足的证据来证明,尤其是想要在某一方面有深入发展的时候。

猜你在找的Oracle相关文章