Précédent   Forum des professionnels en informatique > Bases de données > MySQL > Requêtes
Requêtes Forum d'entraide sur les requêtes MySQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 21/07/2011, 11h41   #1
Nouveau Membre du Club
 
Inscription : septembre 2008
Messages : 115
Détails du profil
Informations forums :
Inscription : septembre 2008
Messages : 115
Points : 28
Points : 28
Par défaut fonction count en InooDB

Bonjour,

J'ai lu qu'il y avait un petit souci avec la fonction ci-dessous en InnoDb:
Code :
SELECT COUNT(*) FROM maTable;
Vu ici:
http://dev.mysql.com/doc/refman/5.0/...trictions.html
Citation:
InnoDB does not keep an internal count of rows in a table because concurrent transactions might “see” different numbers of rows at the same time. To process a SELECT COUNT(*) FROM t statement, InnoDB must scan an index of the table, which takes some time if the index is not entirely in the buffer pool. If your table does not change often, using the MySQL query cache is a good solution. To get a fast count, you have to use a counter table you create yourself and let your application update it according to the inserts and deletes it does. If an approximate row count is sufficient, SHOW TABLE STATUS can be used. See Section 13.2.13.1, “InnoDB Performance Tuning Tips”.
Je ne suis pas sure de tout comprendre... Est ce que cela veut dire qu'en utilisant des requetes de ce type:
Code :
SELECT Count(clefPrimaire) FROM maTable WHERE colone='toto';
Il n'y a pas de problème?

Je ne veux pas trop m'avancer mais je crois comprendre que:
- COUNT(*) est plus rapide que COUNT(clefPrimaire)
- COUNT(*) ne renvoie pas forcement la bonne valeur car il n'y a pas de table qui maintient un compteur (Tout ca pour permettre les transactions)

Je ne sais plus quoi utiliser...
Vilukariok est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/07/2011, 11h48   #2
Membre Expert
 
Avatar de Yanika_bzh
 
Homme Yannick
Ingénieur Etudes & Developpements
Inscription : février 2006
Messages : 1 125
Détails du profil
Informations personnelles :
Nom : Homme Yannick
Localisation : France, Deux Sèvres (Poitou Charente)

Informations professionnelles :
Activité : Ingénieur Etudes & Developpements
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : février 2006
Messages : 1 125
Points : 1 670
Points : 1 670
Citation:
COUNT(*) est plus rapide que COUNT(clefPrimaire)
Non

Citation:
COUNT(*) ne renvoie pas forcement la bonne valeur car il n'y a pas de table qui maintient un compteur (Tout ca pour permettre les transactions)
Non, cela ne concerne que les performances
__________________
Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)
Yanika_bzh est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/07/2011, 13h47   #3
Nouveau Membre du Club
 
Inscription : septembre 2008
Messages : 115
Détails du profil
Informations forums :
Inscription : septembre 2008
Messages : 115
Points : 28
Points : 28
La différence se situe donc uniquement au niveau des performances?
Vilukariok est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 21/07/2011, 14h14   #4
Membre Expert
 
Inscription : août 2008
Messages : 1 271
Détails du profil
Informations forums :
Inscription : août 2008
Messages : 1 271
Points : 1 929
Points : 1 929
count(*) <=> count(PK) car une clé primaire est unique not null, count(*) s'appuie sur la PK.
count(*) <> count(colonne) car count(colonne) ne compte pas les nulls.

Citation:
Envoyé par Vilukariok Voir le message
COUNT(*) ne renvoie pas forcement la bonne valeur car il n'y a pas de table qui maintient un compteur (Tout ca pour permettre les transactions)
non, la phrase :
Citation:
InnoDB does not keep an internal count of rows in a table because concurrent transactions might “see” different numbers of rows at the same time.
fait plutôt référence à Consistent Nonlocking Reads
skuatamad est déconnecté   Envoyer un message privé Réponse avec citation 10
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 00h35.


 
 
 
 
Partenaires

Hébergement Web