Discussion :

[farenheiit]

Bonjour,

j'aurais voulu savoir quel était la meilleure solution pour faire un count dans une table.
Est-ce le count(*)? count(1)? count(PrimaryKey)?

[orafrance]

ça n'a aucune importance

Moi j'aime bien mettre le nom de la colonne qui m'intéresse et si c'est les lignes sans que la colonne importe alors je mets 1... mais tu peux mettre ce que tu veux

[farenheiit]

donc y'a pas de meilleure performance avec count(PrimaryKey) plutot que count(*)? 1 DBA y'a quelques années m'avait fait modifier toutes mes lignes de codes pour remplacer les count(*) par des count sur la Primary Key.

[orafrance]

mais les versions d'Oracle évolue et l'optimiseur avec Il me semble que ça n'a plus d'importance au moins depuis la 8i

[Invité]

C'est depuis la version 8i (peut-être même avant, mais je suis moins sûr de mon coup...) que l'optimiseur s'arrange avec le count( ???? ) et passe outre ce qu'il y a entre parenthèse.
Mais avant, c'est sûr qu'il fallait faire attention !

[dgi77]

On dit toujours que le COUNT(*) est un peu plus lent...

Par contre, attention : un COUNT sur une colonne ne compte pas les enreg. dont la colonne en question vaut null !

[DAB.cz]

La meilleure solution est ne pas faire un count du tout.
Quelle est la raison pour ça?

DAB

[dgi77]

OK, mais qu'est-ce que tu proposes ?

[orafrance]

On dit toujours que le COUNT(*) est un peu plus lent...

et ce n'est pas fondé : http://asktom.oracle.com/pls/asktom/...:1156159920245

[orafrance]

La meilleure solution est ne pas faire un count du tout.
Quelle est la raison pour ça?

DAB

probablement un COUNT avec GROUP BY parce que GROUP BY fait du tri

Sinon, pas de souci

[DAB.cz]

Peut-être l'order suivant suffit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select 1 from dual where exists (select 1 from matable)

Si le count est inévitable, j'utiliserais count (1), mais je crois "count (*)" et "count (pk)" sont les mêmes (10g). En cas de lenteur inadmissible, on peut estimer (de max. PRIMARY valeur par ex.) ou tenir la valeur (selectée une fois) pour la session ou .....

DAB

[Invité]

Si le count est inévitable, j'utiliserais count (1), mais je crois "count (*)" et "count (pk)" sont les mêmes (10g).

C'est exactement la même chose depuis la version 8i !! Cf le lien vers asktom ci-dessus !

[orafrance]

Peut-être l'order suivant suffit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select 1 from dual where exists (select 1 from matable)

ce n'est pas du tout un compte dans ce cas... pour un test d'existence c'est parfait mais si c'est bien le nombre de lignes dont on a besoin le COUNT est indispensable

[DAB.cz]

oui oui, mais on peut souvent voir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select count (1) into xcn from matable;
if xcn > 0 then
  ...

(La meilleure solution est ne pas faire un count du tout.)

DAB

[laurentschneider]

On dit toujours que le COUNT(*) est un peu plus lent...

on disait aussi que la terre était plate il y a qq temps...

Non, c'est le contraire, dans le pire des cas, COUNT(*) est aussi rapide que count(primarykey) voire COUNT(1), mais le plus efficace et le plus logique est COUNT(*),

Il n'existe à ce jour aucun exemple d'une expression différente et plus rapide que COUNT(*)

[laurentschneider]

C'est exactement la même chose depuis la version 8i !! Cf le lien vers asktom ci-dessus !

c'est assez juste car l'optimiseur reconnait les expressions equivalentes à count(*), à savoir COUNT(not_null_expression).

OCM Grégory Guillou a cependant trouvé un exemple en 11g où il vallait mieux employer count(*) ;-)

http://www.pythian.com/blogs/627/ora...unt-and-count1

[orafrance]

Selon la régle qui veut qu'une version d'Oracle ne doit pas être installé avant la 2° release, je pense qu'on va attendre la 11.2 avant de tirer des conclusions

Ceci étant dit, l'exemple est pour le moins étrange... la logique aurait voulu (selon moi ) qu'une vue qui référence des colonnes d'une table soit invalidé quand la table change et pas une vue qui ne compte que les lignes sans se soucier des colonnes... Oracle a ses raisons que la raison n'a pas

[laurentschneider]

pour démontrer le non-sens de COUNT(PK), voici un petit exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SQL> create table t(pk, n, c) as select rpad(rownum,4000,'x'),0, 
    to_clob(rpad(rownum,4000,'x')) from all_objects where rownum<=1000;
Table created.
SQL> create index pk on t(pk);
Index created.
SQL> create index n on t(n);
Index created.
SQL> alter table t add primary key(pk);
Table altered.
SQL> alter table t modify (n not null);
Table altered.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> set autotrace on
SQL> select count(pk) from t;
 COUNT(PK)
----------
      1000
Execution Plan
----------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |     1 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE       |      |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| N    |   921 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------

Comme on le voit, COUNT(PK) n'utilise pas le gros index PK varchar2(4000) de la clé primaire mais bien le petit index N number. Donc COUNT(PK) est identifié comme un count(*) et traduit par l'optimiseur.

[laurentschneider]

Ceci étant dit, l'exemple est pour le moins étrange... la logique aurait voulu (selon moi ) qu'une vue qui référence des colonnes d'une table soit invalidé quand la table change et pas une vue qui ne compte que les lignes sans se soucier des colonnes... Oracle a ses raisons que la raison n'a pas

Oui, Oracle aura dû constater que 1 était une expression non-nulle et ainsi le traduire en *

[farenheiit]

bon ba merci à tous pour vos réponses