Quelle est la meilleure maniere de faire une count? [Résolu]

[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

[7gyY9w1ZY6ySRgPeaefZ]

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]

Envoyé par dgi77

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]

Envoyé par DAB.cz

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 :

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

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par DAB.cz

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]

Envoyé par DAB.cz

Peut-être l'order suivant suffit:

Code :

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 :

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]

Envoyé par dgi77

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]

Envoyé par Jerome_Mtl

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 :

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 :

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]

Envoyé par orafrance

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