J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer
le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ?
Car j'ai une table avec plusieur milions d'enregistrements et quand je fais :
select count(*) from maTable with(nolock) desfois c'est tres tres long ...
Merci beaucoup à celui qui connai cette proc stok.
Michael.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce moment ?
De mémoire l'info est disponible dans la table système des index (et également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, peut-être en regardant les index).
Patrice
--
"Twister" a écrit dans le message de news:
Bonjour,
J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ?
Car j'ai une table avec plusieur milions d'enregistrements et quand je
fais :
select count(*) from maTable with(nolock) desfois c'est tres tres long ...
Merci beaucoup à celui qui connai cette proc stok. Michael.
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce
moment ?
De mémoire l'info est disponible dans la table système des index (et
également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a
ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me
demande d'ailleurs si l'info n'est pas déjà récupérée indirectement,
peut-être en regardant les index).
Patrice
--
"Twister" <Twister@discussions.microsoft.com> a écrit dans le message de
news:25DB1747-7D4F-4DA6-BB78-832BBDB184CB@microsoft.com...
Bonjour,
J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer
le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ?
Car j'ai une table avec plusieur milions d'enregistrements et quand je
fais :
select count(*) from maTable with(nolock) desfois c'est tres tres long ...
Merci beaucoup à celui qui connai cette proc stok.
Michael.
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce moment ?
De mémoire l'info est disponible dans la table système des index (et également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, peut-être en regardant les index).
Patrice
--
"Twister" a écrit dans le message de news:
Bonjour,
J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ?
Car j'ai une table avec plusieur milions d'enregistrements et quand je
fais :
select count(*) from maTable with(nolock) desfois c'est tres tres long ...
Merci beaucoup à celui qui connai cette proc stok. Michael.
Patrice
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000 lignes. Pas de différence particulière (le SELECT est plus lent mais me donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes). Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" a écrit dans le message de news:
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce moment ?
De mémoire l'info est disponible dans la table système des index (et également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, peut-être en regardant les index).
Patrice
--
"Twister" a écrit dans le message de news: > Bonjour, > > J'ai entendu parlé qu'il existai une procedure stokée system pour
renvoyer
> le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce
?
> > Car j'ai une table avec plusieur milions d'enregistrements et quand je fais : > select count(*) from maTable with(nolock) desfois c'est tres tres long
...
> > Merci beaucoup à celui qui connai cette proc stok. > Michael.
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000
lignes. Pas de différence particulière (le SELECT est plus lent mais me
donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes).
Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" <nobody@nowhere.com> a écrit dans le message de
news:OzVqgTLKFHA.508@TK2MSFTNGP12.phx.gbl...
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce
moment ?
De mémoire l'info est disponible dans la table système des index (et
également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a
ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me
demande d'ailleurs si l'info n'est pas déjà récupérée indirectement,
peut-être en regardant les index).
Patrice
--
"Twister" <Twister@discussions.microsoft.com> a écrit dans le message de
news:25DB1747-7D4F-4DA6-BB78-832BBDB184CB@microsoft.com...
> Bonjour,
>
> J'ai entendu parlé qu'il existai une procedure stokée system pour
renvoyer
> le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce
?
>
> Car j'ai une table avec plusieur milions d'enregistrements et quand je
fais :
> select count(*) from maTable with(nolock) desfois c'est tres tres long
...
>
> Merci beaucoup à celui qui connai cette proc stok.
> Michael.
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000 lignes. Pas de différence particulière (le SELECT est plus lent mais me donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes). Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" a écrit dans le message de news:
"Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce moment ?
De mémoire l'info est disponible dans la table système des index (et également je crois dans les stats mais pas forcément à jour).
J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, peut-être en regardant les index).
Patrice
--
"Twister" a écrit dans le message de news: > Bonjour, > > J'ai entendu parlé qu'il existai une procedure stokée system pour
renvoyer
> le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce
?
> > Car j'ai une table avec plusieur milions d'enregistrements et quand je fais : > select count(*) from maTable with(nolock) desfois c'est tres tres long
...
> > Merci beaucoup à celui qui connai cette proc stok. > Michael.
Twister
Merci beaucoup Patrice pour ton aide. sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000 lignes. Pas de différence particulière (le SELECT est plus lent mais me donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes). Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" a écrit dans le message de news: > "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce > moment ? > > De mémoire l'info est disponible dans la table système des index (et > également je crois dans les stats mais pas forcément à jour). > > J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a > ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me > demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, > peut-être en regardant les index). > > Patrice > > -- > > "Twister" a écrit dans le message de > news: > > Bonjour, > > > > J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer > > le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ? > > > > Car j'ai une table avec plusieur milions d'enregistrements et quand je > fais : > > select count(*) from maTable with(nolock) desfois c'est tres tres long .... > > > > Merci beaucoup à celui qui connai cette proc stok. > > Michael. > >
Merci beaucoup Patrice pour ton aide.
sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif
depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000
lignes. Pas de différence particulière (le SELECT est plus lent mais me
donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes).
Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" <nobody@nowhere.com> a écrit dans le message de
news:OzVqgTLKFHA.508@TK2MSFTNGP12.phx.gbl...
> "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce
> moment ?
>
> De mémoire l'info est disponible dans la table système des index (et
> également je crois dans les stats mais pas forcément à jour).
>
> J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a
> ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me
> demande d'ailleurs si l'info n'est pas déjà récupérée indirectement,
> peut-être en regardant les index).
>
> Patrice
>
> --
>
> "Twister" <Twister@discussions.microsoft.com> a écrit dans le message de
> news:25DB1747-7D4F-4DA6-BB78-832BBDB184CB@microsoft.com...
> > Bonjour,
> >
> > J'ai entendu parlé qu'il existai une procedure stokée system pour
renvoyer
> > le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce
?
> >
> > Car j'ai une table avec plusieur milions d'enregistrements et quand je
> fais :
> > select count(*) from maTable with(nolock) desfois c'est tres tres long
....
> >
> > Merci beaucoup à celui qui connai cette proc stok.
> > Michael.
>
>
Merci beaucoup Patrice pour ton aide. sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
C'est sp_spaceused qui retourne également cette info.
J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800 000 lignes. Pas de différence particulière (le SELECT est plus lent mais me donne 223 ms, le sp_spaceused va par contre lui dans la table sysindexes). Donc au pire je gagne 1/4 s environ...
Qu'est ce que cela donne de ton côté ?
Patrice
--
"Patrice" a écrit dans le message de news: > "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à ce > moment ? > > De mémoire l'info est disponible dans la table système des index (et > également je crois dans les stats mais pas forcément à jour). > > J'aurais tendance à être circonspect avant de remplacer le COUNT(*) (qui a > ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je me > demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, > peut-être en regardant les index). > > Patrice > > -- > > "Twister" a écrit dans le message de > news: > > Bonjour, > > > > J'ai entendu parlé qu'il existai une procedure stokée system pour renvoyer > > le nombre d'enregistrements d'une table tres rapidement. Laquelle es ce ? > > > > Car j'ai une table avec plusieur milions d'enregistrements et quand je > fais : > > select count(*) from maTable with(nolock) desfois c'est tres tres long .... > > > > Merci beaucoup à celui qui connai cette proc stok. > > Michael. > >
Patrice
Donc tu me confirmes que ton SELECT * FROM MaTable est beaucoup long que le sp_spaceused ? Tu peux nous donner un ordre de grandeur par curiosité...
Patrice
--
"Twister" a écrit dans le message de news:
Merci beaucoup Patrice pour ton aide. sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
> C'est sp_spaceused qui retourne également cette info. > > J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800
000
> lignes. Pas de différence particulière (le SELECT est plus lent mais me > donne 223 ms, le sp_spaceused va par contre lui dans la table
sysindexes).
> Donc au pire je gagne 1/4 s environ... > > Qu'est ce que cela donne de ton côté ? > > Patrice > > -- > > "Patrice" a écrit dans le message de > news: > > "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à
ce
> > moment ? > > > > De mémoire l'info est disponible dans la table système des index (et > > également je crois dans les stats mais pas forcément à jour). > > > > J'aurais tendance à être circonspect avant de remplacer le COUNT(*)
(qui a
> > ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je
me
> > demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, > > peut-être en regardant les index). > > > > Patrice > > > > -- > > > > "Twister" a écrit dans le message
de
> > news: > > > Bonjour, > > > > > > J'ai entendu parlé qu'il existai une procedure stokée system pour > renvoyer > > > le nombre d'enregistrements d'une table tres rapidement. Laquelle es
ce
> ? > > > > > > Car j'ai une table avec plusieur milions d'enregistrements et quand
je
> > fais : > > > select count(*) from maTable with(nolock) desfois c'est tres tres
long
> .... > > > > > > Merci beaucoup à celui qui connai cette proc stok. > > > Michael. > > > > > > >
Donc tu me confirmes que ton SELECT * FROM MaTable est beaucoup long que le
sp_spaceused ? Tu peux nous donner un ordre de grandeur par curiosité...
Patrice
--
"Twister" <Twister@discussions.microsoft.com> a écrit dans le message de
news:B1964582-F57F-46A7-A7E3-69BC8988B681@microsoft.com...
Merci beaucoup Patrice pour ton aide.
sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif
depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
> C'est sp_spaceused qui retourne également cette info.
>
> J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800
000
> lignes. Pas de différence particulière (le SELECT est plus lent mais me
> donne 223 ms, le sp_spaceused va par contre lui dans la table
sysindexes).
> Donc au pire je gagne 1/4 s environ...
>
> Qu'est ce que cela donne de ton côté ?
>
> Patrice
>
> --
>
> "Patrice" <nobody@nowhere.com> a écrit dans le message de
> news:OzVqgTLKFHA.508@TK2MSFTNGP12.phx.gbl...
> > "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à
ce
> > moment ?
> >
> > De mémoire l'info est disponible dans la table système des index (et
> > également je crois dans les stats mais pas forcément à jour).
> >
> > J'aurais tendance à être circonspect avant de remplacer le COUNT(*)
(qui a
> > ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je
me
> > demande d'ailleurs si l'info n'est pas déjà récupérée indirectement,
> > peut-être en regardant les index).
> >
> > Patrice
> >
> > --
> >
> > "Twister" <Twister@discussions.microsoft.com> a écrit dans le message
de
> > news:25DB1747-7D4F-4DA6-BB78-832BBDB184CB@microsoft.com...
> > > Bonjour,
> > >
> > > J'ai entendu parlé qu'il existai une procedure stokée system pour
> renvoyer
> > > le nombre d'enregistrements d'une table tres rapidement. Laquelle es
ce
> ?
> > >
> > > Car j'ai une table avec plusieur milions d'enregistrements et quand
je
> > fais :
> > > select count(*) from maTable with(nolock) desfois c'est tres tres
long
> ....
> > >
> > > Merci beaucoup à celui qui connai cette proc stok.
> > > Michael.
> >
> >
>
>
>
Donc tu me confirmes que ton SELECT * FROM MaTable est beaucoup long que le sp_spaceused ? Tu peux nous donner un ordre de grandeur par curiosité...
Patrice
--
"Twister" a écrit dans le message de news:
Merci beaucoup Patrice pour ton aide. sp_spaceused fonctionne tres tres bien ;o).
En faite mon select count(*) était long lorsque sql server était inactif depuis un certain temps. Mais la ca marche nikel.
Encore merci pour l'info ;o)
"Patrice" wrote:
> C'est sp_spaceused qui retourne également cette info. > > J'ai fait un essai vite fait mais dans une appli mais je n'ai que 800
000
> lignes. Pas de différence particulière (le SELECT est plus lent mais me > donne 223 ms, le sp_spaceused va par contre lui dans la table
sysindexes).
> Donc au pire je gagne 1/4 s environ... > > Qu'est ce que cela donne de ton côté ? > > Patrice > > -- > > "Patrice" a écrit dans le message de > news: > > "Des fois" ? N'y aurait il pas autre chose de consommateur en cours à
ce
> > moment ? > > > > De mémoire l'info est disponible dans la table système des index (et > > également je crois dans les stats mais pas forcément à jour). > > > > J'aurais tendance à être circonspect avant de remplacer le COUNT(*)
(qui a
> > ma connaissance ne lit pas toutes les lignes pour récupérer l'info, je
me
> > demande d'ailleurs si l'info n'est pas déjà récupérée indirectement, > > peut-être en regardant les index). > > > > Patrice > > > > -- > > > > "Twister" a écrit dans le message
de
> > news: > > > Bonjour, > > > > > > J'ai entendu parlé qu'il existai une procedure stokée system pour > renvoyer > > > le nombre d'enregistrements d'une table tres rapidement. Laquelle es
ce
> ? > > > > > > Car j'ai une table avec plusieur milions d'enregistrements et quand
je
> > fais : > > > select count(*) from maTable with(nolock) desfois c'est tres tres
long
> .... > > > > > > Merci beaucoup à celui qui connai cette proc stok. > > > Michael. > > > > > > >
Nicolas CUVILLIER
Bonjour
l'information retournee par sp_spaceused n'est pas garantie etre exacte. C'est un chiffre que sqlserver essaye de garder a jour, et qui est remis a jour par les check sur la base. Si tu desires un nombre approximatif c'est parfait, et c'est le plus rapide.
Quand tu fais un select count(*), sqlserver ne lit pas les donnees, mais choisit un index non cluster, et compte le nombre de clefs dans l'index. Le nombre d'i/o est donc sensiblement egal au nombre de page de ton index, si rien n'est dans le cache. Je n'ai pas une grosse base chargee, mais pour 50000 lignes, sur un portable (disque non rapide), cache vide, le select count(*) est immediat.
Il me semble que tu ne dois pas avoir d'index non cluster sur ta table, et que sqlserver est oblige de lire toutes les donnees.
/*** Plus d'infos + technique ***/ Si tu veux estimer les i/o et donc le temps necesaire a ton select count(*), tu peux proceder comme suit :
Retrouve les infos concernant les index pour ta table :
select indid, name, rowcnt, dpages from sysindexes where id in (select id from sysobjects where name = 'nom_table')
indid indique le type d'information : 0 = nombre de pages pour stocker les donnes d'une table sans index cluster 1 = nombre de pages pour un index cluster (index et data)
1 = nombre de pages pour un index non cluster (pages d'index seulement)
Si sqlserver ne prenait pas le bon index, tu peux faire un select count(columns) form table, ou columns est une colonne de ton index, des fois cela peut aider, mais il faudrait voir ta table, et tes index pour comprendre ce qui se passe. Bonne chance Nicolas
Bonjour
l'information retournee par sp_spaceused n'est pas garantie etre exacte.
C'est un
chiffre que sqlserver essaye de garder a jour, et qui est remis a jour par
les check
sur la base. Si tu desires un nombre approximatif c'est parfait, et c'est le
plus
rapide.
Quand tu fais un select count(*), sqlserver ne lit pas les donnees, mais
choisit
un index non cluster, et compte le nombre de clefs dans l'index. Le nombre
d'i/o est
donc sensiblement egal au nombre de page de ton index, si rien n'est dans le
cache.
Je n'ai pas une grosse base chargee, mais pour 50000 lignes, sur un portable
(disque
non rapide), cache vide, le select count(*) est immediat.
Il me semble que tu ne dois pas avoir d'index non cluster sur ta table, et
que sqlserver
est oblige de lire toutes les donnees.
/*** Plus d'infos + technique ***/
Si tu veux estimer les i/o et donc le temps necesaire a ton select count(*),
tu peux
proceder comme suit :
Retrouve les infos concernant les index pour ta table :
select indid, name, rowcnt, dpages from sysindexes where id in
(select id from sysobjects where name = 'nom_table')
indid indique le type d'information :
0 = nombre de pages pour stocker les donnes d'une table sans index cluster
1 = nombre de pages pour un index cluster (index et data)
1 = nombre de pages pour un index non cluster (pages d'index seulement)
Si sqlserver ne prenait pas le bon index, tu peux faire un select
count(columns) form table,
ou columns est une colonne de ton index, des fois cela peut aider, mais il
faudrait voir
ta table, et tes index pour comprendre ce qui se passe.
Bonne chance
Nicolas
l'information retournee par sp_spaceused n'est pas garantie etre exacte. C'est un chiffre que sqlserver essaye de garder a jour, et qui est remis a jour par les check sur la base. Si tu desires un nombre approximatif c'est parfait, et c'est le plus rapide.
Quand tu fais un select count(*), sqlserver ne lit pas les donnees, mais choisit un index non cluster, et compte le nombre de clefs dans l'index. Le nombre d'i/o est donc sensiblement egal au nombre de page de ton index, si rien n'est dans le cache. Je n'ai pas une grosse base chargee, mais pour 50000 lignes, sur un portable (disque non rapide), cache vide, le select count(*) est immediat.
Il me semble que tu ne dois pas avoir d'index non cluster sur ta table, et que sqlserver est oblige de lire toutes les donnees.
/*** Plus d'infos + technique ***/ Si tu veux estimer les i/o et donc le temps necesaire a ton select count(*), tu peux proceder comme suit :
Retrouve les infos concernant les index pour ta table :
select indid, name, rowcnt, dpages from sysindexes where id in (select id from sysobjects where name = 'nom_table')
indid indique le type d'information : 0 = nombre de pages pour stocker les donnes d'une table sans index cluster 1 = nombre de pages pour un index cluster (index et data)
1 = nombre de pages pour un index non cluster (pages d'index seulement)
Si sqlserver ne prenait pas le bon index, tu peux faire un select count(columns) form table, ou columns est une colonne de ton index, des fois cela peut aider, mais il faudrait voir ta table, et tes index pour comprendre ce qui se passe. Bonne chance Nicolas
Twister
Merci beaucoup pour votre aide ;o)
Bilan : le sp_spaceused est de loin le plus rapide et quelquesoit la charge de mon serveur la réponse est instantanée. Mais effectivement le résultat est une valeur approchée.. (moins 55 enregistrements pour 4 milions d'enregistrements) ca reste tres correct pour ce dont j'ai besoin.
Lorsque mon serveur est en pleine charge le select count(*) peut monter jusqu'a plusieur secondes de recherche... lorsqe je précise une colone select count(cle_primaire) c'est un peu plus rapide...mais plusieur secondes quand meme.. Mais apres la premiere execution les trois méthodes sont quasi semblables...
Merci ...
Merci beaucoup pour votre aide ;o)
Bilan :
le sp_spaceused est de loin le plus rapide et quelquesoit la charge de mon
serveur la réponse est instantanée.
Mais effectivement le résultat est une valeur approchée..
(moins 55 enregistrements pour 4 milions d'enregistrements) ca reste tres
correct pour ce dont j'ai besoin.
Lorsque mon serveur est en pleine charge le select count(*) peut monter
jusqu'a plusieur secondes de recherche... lorsqe je précise une colone select
count(cle_primaire) c'est un peu plus rapide...mais plusieur secondes quand
meme.. Mais apres la premiere execution les trois méthodes sont quasi
semblables...
Bilan : le sp_spaceused est de loin le plus rapide et quelquesoit la charge de mon serveur la réponse est instantanée. Mais effectivement le résultat est une valeur approchée.. (moins 55 enregistrements pour 4 milions d'enregistrements) ca reste tres correct pour ce dont j'ai besoin.
Lorsque mon serveur est en pleine charge le select count(*) peut monter jusqu'a plusieur secondes de recherche... lorsqe je précise une colone select count(cle_primaire) c'est un peu plus rapide...mais plusieur secondes quand meme.. Mais apres la premiere execution les trois méthodes sont quasi semblables...
