Tu pourrais faire un explain plan de tes requêtes ? EXPLAIN SELECT ...
A priori quand tu fais une recherche il doit utiliser l'index CliCBDate, il filtre par AutoIncrementCli, mais il doit s'arréter à CodeBarrePosition parce que tu fais un Like, du coup pour le BETWEEN sur DateNum il est obligé de parcourir toute la table, tu aurais le même problème avec un ORDER BY, alors que quand il trouve 10 résultats il arrête de parcourir la table.
Je ne suis plus très sur de la manière dont fonctionne MySQL sur ce type de clef, mais tu peux tenter avec :
KEY `CliDate` (`AutoIncrementCli`, `DateNum`)
ou
KEY `Date` (`DateNum`)
10 mars 2009 à 11:06
Merci.
Ce qui est curieux c'est que l'EXPLAIN semble dire qu'il n'y a pas tant que ça à parcourir :
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331' LIMIT 10;
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.52 sec)
Je doute un peu de son efficacité. Si j'ai bien compris, le nombre de lignes à parcourir (rows) est de 30.934 ce qui serait très rapide à faire.
Ma première clef était celle-ci. Mais les résultats étaient pires :
KEY `DateCB` (`DateNum`,`CodeBarrePosition`,`AutoIncrementCli`)
Je vais tenter ta version. Ma première clef était stupide car le champ AutoIncrementCli est très fortement dupliqué (il y a environ 20 occurences possibles).
10 mars 2009 à 11:17
LeChat a écrit
Je vais tenter ta version. Ma première clef était stupide car le champ AutoIncrementCli est très fortement dupliqué (il y a environ 20 occurences possibles).
Je dis peut-être une conerie, mais tu peux essayer de réorganiser la requête en mettant les éléments plus restrictifs en premier :
SELECT * FROM 05pointage WHERE DateNum BETWEEN '050100' AND '050331' AND CodeBarrePosition LIKE '3360%' AND AutoIncrementCli=16 LIMIT 10 ;
Par contre même avec une requête non optimisée ça ne devrait pas mettre autant de temps 61M de lignes ce n'est pas si énorme que ça ...
10 mars 2009 à 11:29
`CodeBarrePosition` varchar(30) NOT NULL,
Tu es sûr de le vouloir en var char ? une recherche dessus est beaucoup plus lent que des entiers (et dans les extraits de ta table je ne vois que des entiers)
Dernière modification le 10/03/09 à 11:39 par Kane
10 mars 2009 à 11:35
Il peut y avoir des caractères alphabétiques dans le champ CodeBarrePosition.
Pour l'ordre dans la requête, il me semble que MySQL s'occupe d'arranger au mieux (ce que l'on voit dans l'EXPLAIN).
10 mars 2009 à 11:41
Fais :
SHOW INDEX FROM `05pointage` ;
pour voir ...
Tu es sûr que ta table d'index est bien créé ? Si tu as modifié les clefs, il me semble qu'il faut la reconstruire. (par exemple, si tu rajoute une clef, elle ne sera indexée que pour les nouveaux enregistrements)
10 mars 2009 à 11:51
Kane a écrit
Par contre même avec une requête non optimisée ça ne devrait pas mettre autant de temps 61M de lignes ce n'est pas si énorme que ça ...
Je suis assez étonné aussi.
10 mars 2009 à 12:01
Merci, je ne connaissais pas la commande :)
mysql> SHOW INDEX FROM `05pointage` ;
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| 05pointage | 0 | PRIMARY | 1 | AutoIncrementFic | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 0 | PRIMARY | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 0 | PRIMARY | 3 | NumCD | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 0 | PRIMARY | 4 | NumImg | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 0 | PRIMARY | 5 | DebutImg | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 0 | PRIMARY | 6 | HautImg | A | 61960184 | NULL | NULL | | BTREE | |
| 05pointage | 1 | CliCBDate | 1 | AutoIncrementCli | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 1 | CliCBDate | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | |
| 05pointage | 1 | CliCBDate | 3 | DateNum | A | NULL | NULL | NULL | | BTREE | |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
9 rows in set (0.00 sec)
10 mars 2009 à 13:05
Kane a écrit
Fais :
SHOW INDEX FROM `05pointage` ;
pour voir ...
Tu es sûr que ta table d'index est bien créé ? Si tu as modifié les clefs, il me semble qu'il faut la reconstruire. (par exemple, si tu rajoute une clef, elle ne sera indexée que pour les nouveaux enregistrements)
Oui. Ca va limite plus vite de flinguer les tables et de refaire les mises à jour (ce que je fais). Donc pas de doute.
C'est curieux, il semble que je n'ai pas le même problème sur une autre table (plus récente).
Par contre, elle est moins fournie pour l'instant (13 900 387). Mais chercher sur un mois, qu'on trouve ou non, est très rapide.
mysql> SHOW INDEX FROM `09pointage` ;
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| 09pointage | 0 | PRIMARY | 1 | AutoIncrementFic | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 3 | NumCD | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 4 | NumImg | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 5 | DebutImg | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 6 | HautImg | A | 13919571 | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 1 | AutoIncrementCli | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 3 | DateNum | A | NULL | NULL | NULL | | BTREE | |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
9 rows in set (0.00 sec)
10 mars 2009 à 13:11
SimOOn a écritKane a écrit
Par contre même avec une requête non optimisée ça ne devrait pas mettre autant de temps 61M de lignes ce n'est pas si énorme que ça ...
Je suis assez étonné aussi.
Peut-être qu'en augmentant des buffers de MySQL ?
Base actuelle :
10 mars 2009 à 13:14
LeChat a écrit
Peut-être qu'en augmentant des buffers de MySQL ?
Augmenter les buffers ne te permettront pas de passer de 14min à 1s.
T'as pu déterminer si une restriction en particulier causait le problème ?
Dernière modification le 10/03/09 à 14:03 par SimOOn
10 mars 2009 à 14:02
SimOOn a écritLeChat a écrit
Peut-être qu'en augmentant des buffers de MySQL ?
Augmenter les buffers ne te permettront pas de passer de 14min à 1s.
T'as pu déterminer si une restriction en particulier causait le problème ?
Non. Je ne sais pas comment MySQL procède et je n'arrive pas à déterminer de point limitant.
Et comme je l'ai dit, sur la table récente cela semble se comporte correctement.
Je me demande s'il n'y a pas des données à la con dans la table 05pointage qui causerait des clefs gênantes (genre très fortement dupliquées).
10 mars 2009 à 14:22
tente un check et une analyse pour les stats et refait un show indexes
CHECK TABLE `05pointage`
ANALYZE TABLE `05pointage`
10 mars 2009 à 15:01
LeChat a écrit
Merci, je ne connaissais pas la commande :)
mysql> SHOW INDEX FROM `05pointage` ; +------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+ | 05pointage | 0 | PRIMARY | 1 | AutoIncrementFic | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 0 | PRIMARY | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 0 | PRIMARY | 3 | NumCD | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 0 | PRIMARY | 4 | NumImg | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 0 | PRIMARY | 5 | DebutImg | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 0 | PRIMARY | 6 | HautImg | A | 61960184 | NULL | NULL | | BTREE | | | 05pointage | 1 | CliCBDate | 1 | AutoIncrementCli | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 1 | CliCBDate | 2 | CodeBarrePosition | A | NULL | NULL | NULL | | BTREE | | | 05pointage | 1 | CliCBDate | 3 | DateNum | A | NULL | NULL | NULL | | BTREE | | +------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+ 9 rows in set (0.00 sec)
Mouai, il y a quelque chose de pas net sur ta table. Tu as Cardinality=NULL pour la plupart de tes clefs, alors que c'est censé te donner le nombre d'enregistrements uniques de cette clef.
Je ne dis pas que ce que tu as fait est mauvais, mais personnellement je ne déclare qu'une seule clef primaire par table. Pour accélérer les requêtes tu peux indexer les autres colonnes.
Par exemple, si tu veux accélérer toujours la même requête, je déclarerai la table de la façon suivante :
CREATE TABLE `05pointage` (
`AutoIncrementFic` int(1) unsigned NOT NULL,
`AutoIncrementCli` int(1) unsigned NOT NULL,
`NumImg` int(8) unsigned NOT NULL,
`NumCD` varchar(8) NOT NULL,
`Caisson` varchar(14) NOT NULL,
`Enveloppe` varchar(25) NOT NULL,
`CodeBarrePosition` varchar(30) NOT NULL,
`DateNum` int(8) unsigned NOT NULL,
`SaisieDep` char(2) NOT NULL,
`CodeBarrePage` varchar(20) NOT NULL,
`SaisieManuelle` char(1) NOT NULL,
`DebutImg` smallint(4) unsigned NOT NULL,
`HautImg` smallint(4) unsigned NOT NULL,
`NumPos` char(2) NOT NULL,
`Pad` char(1) NOT NULL,
PRIMARY KEY (`AutoIncrementFic`),
INDEX mon_index (`AutoIncrementCli`,`CodeBarrePosition`,`DateNum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Edit : bon, en faitn je ne vois pas trop la différence entre KEY et INDEX ...
cf la doc :
index multiples
index simple
Dernière modification le 10/03/09 à 15:56 par Kane
10 mars 2009 à 15:49
Autre solution, tu déclares tes index sur plusieurs lignes, comme ça ils seront valides pour d'autres requêtes.
10 mars 2009 à 15:58
non il ne peut utiliser qu'un seul index à la fois.
tu peux retenter ces explain plan :
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105';
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105' LIMIT 10;
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331';
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331' LIMIT 10;
et aussi
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN 50100 AND 50105 LIMIT 10;
au cas où, mais ej doute que ça change quoi ce soit.
10 mars 2009 à 16:30
Akshell a écrit
non il ne peut utiliser qu'un seul index à la fois.
Ouai, mais il peut en créer plusieurs pour optimiser d'autres requêtes. Il peut même créer un index multiple sur les 3 colonnes ET 3 indexes pour chaque colonnes.
Car si il fait qu'un seul index multiple, il ne pourra pas être utilisé dans tous les cas. Par exemple, avec sa déclaration, une requête sur DateNum n'utilisera pas les index (car pas déclaré en première position d'un index multiple), elle sera donc lente. Par contre avec la déclaration suivante (sauf erreur de ma part) ça le sera :
CREATE TABLE `05pointage` (
`AutoIncrementFic` int(1) unsigned NOT NULL,
`AutoIncrementCli` int(1) unsigned NOT NULL,
`NumImg` int(8) unsigned NOT NULL,
`NumCD` varchar(8) NOT NULL,
`Caisson` varchar(14) NOT NULL,
`Enveloppe` varchar(25) NOT NULL,
`CodeBarrePosition` varchar(30) NOT NULL,
`DateNum` int(8) unsigned NOT NULL,
`SaisieDep` char(2) NOT NULL,
`CodeBarrePage` varchar(20) NOT NULL,
`SaisieManuelle` char(1) NOT NULL,
`DebutImg` smallint(4) unsigned NOT NULL,
`HautImg` smallint(4) unsigned NOT NULL,
`NumPos` char(2) NOT NULL,
`Pad` char(1) NOT NULL,
PRIMARY KEY (`AutoIncrementFic`),
INDEX mon_index (`AutoIncrementCli`,`CodeBarrePosition`,`DateNum`),
INDEX (`AutoIncrementCli`),
INDEX (`CodeBarrePosition`),
INDEX (`DateNum`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
10 mars 2009 à 17:00
Kane a écrit
Mouai, il y a quelque chose de pas net sur ta table. Tu as Cardinality=NULL pour la plupart de tes clefs, alors que c'est censé te donner le nombre d'enregistrements uniques de cette clef.
Tiens, en relisant la doc je suis tombé sur ça :
Avec l'aide de EXPLAIN, vous pouvez identifier les index à ajouter pour accélérer les commandes SELECT.
Vous devriez souvent utiliser la commande ANALYZE TABLE pour mettre à jour les statistiques de cardinalité de vos tables, qui affectent les choix de l'optimiseur. See Section 13.5.2.1, « Syntaxe de ANALYZE TABLE ».
10 mars 2009 à 17:04
oui s'il en a besoin, mais ça ne répondra à son problème d'aujourd'hui
10 mars 2009 à 17:05
'scuzez, j'avais théâtre :)
Pour la clef primaire, il faut qu'elle soit unique. D'où le choix des champs qui entrent dans sa composition (le champ AutoIncrementFic est dupliqué, il ne peut suffire).
Ensuite, il faut créer au moins la clef qui corresponde le plus aux requêtes que je vais faire. C'est le but de ma clef CliCBDate.
Après, indexer séparément un des champs qui sert à la requête pourrait être utile, mais je ne sais pas comment MySQL procède dans ses recherches et donc s'il y a besoin d'une clef en plus (je pense en particulier à la recherche floue sur le champ CodeBarrePosition).
Pour la Cardinality=NULL, c'est vrai que j'ai aussi trouvé ça chelou.
Je continue à chercher demain au boulot.
Encore merci de votre aide.
11 mars 2009 à 00:13
Akshell a écrit
tente un check et une analyse pour les stats et refait un show indexes
CHECK TABLE `05pointage`
ANALYZE TABLE `05pointage`
Apparemment ça met bien à jour les infos de cardinalité :
mysql> CHECK TABLE `09pointage`;
+--------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------+-------+----------+----------+
| servhot.09pointage | check | status | OK |
+--------------------+-------+----------+----------+
1 row in set (45 min 41.95 sec)
mysql> ANALYZE TABLE `09pointage`;
+--------------------+---------+----------+-----------------------------+
| Table | Op | Msg_type | Msg_text |
+--------------------+---------+----------+-----------------------------+
| servhot.09pointage | analyze | status | Table is already up to date |
+--------------------+---------+----------+-----------------------------+
1 row in set (0.01 sec)
mysql> SHOW INDEX FROM `09pointage` ;
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
| 09pointage | 0 | PRIMARY | 1 | AutoIncrementFic | A | 208150 | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 2 | CodeBarrePosition | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 3 | NumCD | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 4 | NumImg | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 5 | DebutImg | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 0 | PRIMARY | 6 | HautImg | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 1 | AutoIncrementCli | A | 29 | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 2 | CodeBarrePosition | A | 18941668 | NULL | NULL | | BTREE | |
| 09pointage | 1 | CliCBDate | 3 | DateNum | A | 18941668 | NULL | NULL | | BTREE | |
+------------+------------+-----------+--------------+-------------------+-----------+-------------+----------+--------+------+------------+---------+
9 rows in set (0.12 sec)
11 mars 2009 à 15:14
Akshell a écrit
non il ne peut utiliser qu'un seul index à la fois.
tu peux retenter ces explain plan :
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105';
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105' LIMIT 10;
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331';
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331' LIMIT 10;
et aussi
EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN 50100 AND 50105 LIMIT 10;
au cas où, mais ej doute que ça change quoi ce soit.
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105';
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.26 sec)
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050105' LIMIT 10;
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.00 sec)
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331';
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.00 sec)
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN '050100' AND '050331' LIMIT 10;
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.00 sec)
mysql> EXPLAIN SELECT * FROM 05pointage WHERE AutoIncrementCli=16 AND CodeBarrePosition LIKE '3360%' AND DateNum BETWEEN 50100 AND 50105 LIMIT 10;
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
| 1 | SIMPLE | 05pointage | range | CliCBDate | CliCBDate | 40 | NULL | 30934 | Using where |
+----+-------------+------------+-------+---------------+-----------+---------+------+-------+-------------+
1 row in set (0.00 sec)
11 mars 2009 à 15:18
Bon c'est un peu étrange, dans tous les cas il utilise seulement la clef pour effectuer la recherche donc ça ne devrait jamais mettre autant de temps.
11 mars 2009 à 15:26
Répondre au sujet
Vous devez être identifié pour participer à ce topic.
Nicolas le jardinier