Discussion :

[nobs]

Bonjour ttlm,

Je souhaiterais savoir quel devrait être selon vous le l'ordre de grandeur (en seconde ? en minute ?) pour l'exécution d'une simple requête "select count" sur une table contenant 5 millions d'enregistrements (table avec un index sur la PK, le serveur est virtualisé, et je n'en sais pas plus).

autrement dit : je mesure 3 min 30 sec de temps d’exécution, ça choque quelqu'un, ou ça vous semble normal ?


Merci pour toute réponse.
bien cordialement,

nobs

[Kropernic]

Juste pour indication, j'obtiens le résultat en 13 secondes sur une table contenant 95728024 de lignes (et non pas enregistrements) mais ce n'est pas virtualisé chez moi...

Le fait que ce soit virtualisé doit forcément jouer ainsi que la config de l'instance SQL en question.

[nobs]

Ok, merci, tu réponds à ma question... pour info le serveur que tu utilises est il particulièrement performant ? (machine à 1 million de dallors ?)

Par contre quand je parlais d'enregistrement, je parlais du résultat de mon count sans clause where. Le terme "enregistrement" n'était il pas correct ?

[Kropernic]

Ok, merci, tu réponds à ma question... pour info le serveur que tu utilises est il particulièrement performant ? (machine à 1 million de dallors ?)

Mon serveur n'est pas à 1 million de dollars non XD. Voici la bête :
Processor : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 2.34Ghz
RAM : 16 GB
System Type : 64-bit Operating System (Windows Server 2008 R2 Standard)

Quant à la version de l'instance sql en elle-même, c'est pareil que windows. C'est 2008 R2 standard.

Rien de bien fabuleux quoi.

Par contre quand je parlais d'enregistrement, je parlais du résultat de mon count sans clause where. Le terme "enregistrement" n'était il pas correct ?

Dans une table de SGBD(R), on parle de lignes et de colonnes et non pas d'enregistrements et de champs. Le résultat du count donne donc un nombre de lignes (avec ou sans clause where).

Bon après, je comprends bien sûr ce que vous voulez dire si vous me parlez d'enregistrement mais autant rester aussi rigoureux que possible.
Plus d'infos ici.

[nobs]

Ok, merci pour pour vos précisions, je ferai plus attention.

autant rester aussi rigoureux que possible.

Entièrement d'accord !

[aieeeuuuuu]

Bonjour,

Les temps de réponse pour une simple requête comme celle-ci peuvent varier énormément selon plusieurs critères
1/ comme déjà évoqué, la machine bien sûr
2/ la structure de la table visée
3/ la présence d'index pour supporter la requête
4/ la présence des données en cache
5/ Verrous posés sur la table


enfin 3 minutes... ça parait beaucoup, et mon avis le cas 5/ est fort probable.

Notez toutefois que pour connaitre le nombre total de lignes dans une table, vous pouvez vous appuyer sur les données statistiques, le résultat devrait être immédiat (mais dans certains cas pas forcément pertinent).

Dans quel contexte effectuez-vous une telle requête ?

[StringBuilder]

Bon, c'est juste une base de test, mais avec SQL Server 2014 Express, sur mon PC tout pourrave (qui a bientôt 3 ans, sans SSD si rien) j'arrive à lire 1,6 millions de lignes en 2 secondes alors que je suis en train d'alimenter la table à grand coups de blocs d'insertion de 10000 lignes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
create table tblA
(
	id int primary key not null,
	nom varchar(50) not null
);
go
 
declare @i int;
 
select @i = 0;
 
while @i < 10000
begin
	with cte as (
		select 0 val
		union all
		select val + 1 from cte where val < 9999
	)
	insert into tblA (id, nom)
	select val + (@i * 10000), concat('Valeur ', val + (@i * 10000)) from cte option(MAXRECURSION 9999);
	set @i = @i + 1;
end;

En lançant au bout de quelques instants :

Code :

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

select count(*) from tblA;

J'obtiens au bout de 2 secondes :

1 630 163

Au bout de quelques minutes, je relance (toujours en train d'insérer des données massivement comme un porc) :

Au bout de 12 secondes

13 081 308

Au bout de 45 secondes

24 312 431

On voit que la montée en charge est tout sauf linéaire.

Reste à savoir quel est le goulot d'étranglement qui provoque le ralentissement chez toi.
Chez moi c'est visiblement le disque dur qui a du mal à suivre.

Quoi qu'en fait... Cette fois il a lu 40 554 055 lignes en 11 secondes... Et la base fait déjà plus de 1 Go...

43 154 315 en 3 secondes...

Mon PC fait pourtant pas grand chose d'autre... Étrange ces temps de réponse aussi variants. En tout cas, on est loin de 3 minutes !

Voici un copier/coller partiel de sysinfo pour donner un ordre d'idée de ma machine.
Mise à part qu'elle a beaucoup de mémoire (qui sert à rien vu que Express ne peut pas tout utilier) elle a franchement rien de spécial !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Version	6.3.9600 Build 9600
OS Manufacturer	Microsoft Corporation
System Type	x64-based PC
Processor	Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz, 3300 Mhz, 4 Core(s), 4 Logical Processor(s)
Hardware Abstraction Layer	Version = "6.3.9600.17031"
Installed Physical Memory (RAM)	8,00 GB
Total Physical Memory	7,98 GB
Available Physical Memory	1,41 GB
Total Virtual Memory	9,85 GB
Available Virtual Memory	3,48 GB
Page File Space	1,88 GB
Page File	C:\pagefile.sys
Hyper-V - VM Monitor Mode Extensions	Yes
Hyper-V - Second Level Address Translation Extensions	Yes
Hyper-V - Virtualization Enabled in Firmware	Yes
Hyper-V - Data Execution Protection	Yes

Tout est installé dans C:\ ce qui explique une certaine lenteur vu que tempdb et ma base barbottent sur le même disque et se mélangent allègrement les fragments (surtout à 3,8 Go la tampdb, ça commence à faire)

J'ai même poussé le diable avec cette requête sur 50 005 000 de lignes :

Code :

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

select count(*) from tblA where nom like '%10%';

1 minute et 13 secondes alors que la base est en pleine charge et que la colonne n'est pas indexée. 1 990 199 lignes.

[StringBuilder]

Euh... Y'a un truc que je pige pas avec mon test...

Je devrais avoir 100 000 000 lignes dans la base non ?

J'en ai que 50 005 000 (???) Comment j'ai fait mon compte ?

En tout cas, 14 secondes pour les compter à chaque requête.

[nobs]

Dans quel contexte effectuez-vous une telle requête ?

Bonjour,

C'était le premier pas dans ma recherche des causes de la lenteur d'une autre requête (un simple Select sans jointure...).

Et c'est la surprise que j'ai eu en faisant le count qui m'a poussé à chercher confirmation de mon intuition (à savoir : "c'est pas normal que ce soit si long") ici.

le but de ma question était de savoir si j'étais légitime à remonter le problème aux admin locaux.

merci pour les réponses en tout cas.