Discussion :

[guizmo_]

Bonjour,

J'ai un probleme avec un SELECT trop lent en InnoDB (en embedded).

Ma base contient trois tables que voici :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
 
    CREATE TABLE GENERATED_MESSAGE ( 
	id_id_gme INT NOT NULL, 
	tme_since_gme DATETIME NOT NULL,
	tor_since_gme CHAR ( 3 ) NOT NULL,
	tme_until_gme DATETIME,
	int_occur_gme MEDIUMINT NOT NULL,
	stm_status_gme VARCHAR ( 30 ) NOT NULL,
	knd_ima_gme VARCHAR ( 3 ),
	int_event_gme MEDIUMINT NOT NULL,
	cla_class_gme TINYINT NOT NULL,
	int_msn_acf MEDIUMINT NOT NULL,
	id_id_phi INT NOT NULL,
	int_id_syb MEDIUMINT NOT NULL,
	sid_side_bas MEDIUMINT NOT NULL,
	fmc_code_fau INT NOT NULL,
	int_version_top MEDIUMINT NOT NULL,
        boo_gndscan_gme TINYINT(1),
	PRIMARY KEY (id_id_gme),
        INDEX gme_index (int_id_syb, sid_side_bas, fmc_code_fau,   int_version_top)) TYPE = InnoDB
 
 
CREATE TABLE FDCE_CODE (
	id_id_fdv INT NOT NULL AUTO_INCREMENT,
	fde_code_fdv MEDIUMINT  NOT NULL,
	fdt_type_fdv MEDIUMINT  NOT NULL,
	id_id_gme INT NOT NULL,
	boo_isfromcd_fdv TINYINT(1),
	PRIMARY KEY (id_id_fdv, fde_code_fdv),
	INDEX fdecode_index (id_id_gme),
	FOREIGN KEY (id_id_gme) REFERENCES GENERATED_MESSAGE (id_id_gme)) TYPE = InnoDB
 
CREATE TABLE COMPLEMENTARY_DATA (
	id_id_cod INT NOT NULL AUTO_INCREMENT,
	int_set_cod TINYINT NOT NULL,
	bin_codata_cod BLOB,
	tme_newconfirmation_cod DATETIME NOT NULL,
	id_id_gme INT NOT NULL,
	fmcgroup_code_cod MEDIUMINT,
	PRIMARY KEY (id_id_cod),
	INDEX cd_index (id_id_gme),
	FOREIGN KEY (id_id_gme) REFERENCES GENERATED_MESSAGE (id_id_gme)) TYPE = InnoDB

Mon programme remplit ces tables avec 88 000 enregistrements dans GENERATED_MESSAGE, 88 000 dans FDCE_CODE et un peu plus de 13 000 dans COMPLEMENTARY_DATA.

Ensuite, il fait une requete de sélection que voici :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT * 
FROM GENERATED_MESSAGE 
LEFT JOIN COMPLEMENTARY_DATA 
ON GENERATED_MESSAGE.id_id_gme = COMPLEMENTARY_DATA.id_id_gme 
JOIN FDCE_CODE 
ON GENERATED_MESSAGE.id_id_gme = FDCE_CODE.id_id_gme 
WHERE GENERATED_MESSAGE.int_id_syb = 1
AND GENERATED_MESSAGE.sid_side_bas = 8
AND GENERATED_MESSAGE.fmc_code_fau = 112

J'ai à peu près 150 enregistrements de remontés via cette requete.

Ma requete prend 1,6 secondes en InnoDb pour la premiere execution (ensuite, le innodb_buffer_pool est utilisé donc les executions suivantes prennent moins de 1 ms) alors qu'en MyISAM ça prend 120 ms.
Mon index est utilisé pour optimiser la requete.

Je me demande ce qui cloche pour mon premier SELECT en InnoDB car je trouve 1,6s ça fait long pour ma requete. Qu'en pensez-vous?
La machine sur laquelle on teste est dédiée et a un proc Core 2 Duo 6320 1,86 GHz et 2Go RAM.

Je suis en MySQL 4.1.22 et mon fichier my.cnf ne contient aucun parametrage particulier pour InnoDB.

[nounetmasque]

Perso je ne trouve pas que 1.6s soit très long pour des jointures sur des tables contenant autant de ligne.

[guizmo_]

Comment expliquer pourtant le temps de 120 ms en MyISAM par rapport aux 1,6s de InnoDB?

Par ailleurs, j'ai fait un test InnoDB sans mettre d'index sur GENERATED_MESSAGE et j'ai un résultat de 1,8s...

Cela confirme bien que le temps de 1,6s en InnoDB avec index sur GENERATED_MESSAGE n'est pas normal, non?

[gregory.broissard]

Non c'est clair qu'avec des si petits volumes, c'est complétement anormal d'avoir 1,6 secondes.

Peux tu faire un explain sur la requete qu'on voit où il passe?

[guizmo_]

Voici la sortie du EXPLAIN pour la requete :

Code :

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

1
2
3
4
 
>> 1	SIMPLE	GENERATED_MESSAGE	ref	PRIMARY,gme_index	gme_index	10	const,const,const	162	Using where	
>> 1	SIMPLE	COMPLEMENTARY_DATA	ref	cd_index	cd_index	4	Bench.GENERATED_MESSAGE.id_id_gme	1		
>> 1	SIMPLE	FDCE_CODE	ref	fdecode_index	fdecode_index	4	Bench.GENERATED_MESSAGE.id_id_gme	1

[ced]

Bonjour,

Pourquoi faire un produit cartésien (JOIN) sur FDCE_CODE ? Le mot clef JOIN tout seul équivaut à un CROSS JOIN, c'est à dire un produit cartésien (et la condition de jointure derrière ne sert à rien...). Et ça donne 88 000 lignes par 88 000 lignes, ce qui explique très certainement le temps de traitement...

Remplace le JOIN par un INNER JOIN, et ça devrait aller mieux .

ced

[guizmo_]

J'ai mis un INNER JOIN et ça ne va pas mieux, j'ai grosso modo le meme temps : 1,6s à 80 ms près.

Voici le EXPLAIN pour la requete avec l'INNER JOIN :
edit : c'est le meme EXPLAIN que pour la requete avec JOIN tout court

[guizmo_]

Il me semble que par défaut, innodb_buffer_pool_size est égal à 8M.
Enfin c'est ce que je viens de comprendre.

En le passant à 16M : ma requete prend 400 ms
En le passant à 24M : ma requete prend 7 ms


Avec 8M de cache (et donc des accès disques pour ma requete), vous trouvez normal que ma requete prenne 1.6s?

[guizmo_]

Si je teste ma requete de sélection sur d'autres triplés {int_id_syb, sid_side_bas, fmc_code_fau}, j'ai des variations importantes dans mes résultats.

Dans des cas ou j'ai 20 enregistrements remontés, ma requete prend moins de 20ms.

Je pense que le problème de lenteur de ma requete précédente vient de mon exemple en lui-meme : répartition des données pas idéale => index sans effet sur les perfs dans mon exemple?

Est-ce qqun a une url ou qq chose (une doc ou des graphes) avec les performances de mysql sur plusieurs requetes?

[guizmo_]

J'ai essayé un nouveau truc dans mon programme

-un premier scénario avec connexion à la base, un drop tables, create tables, insert des données, puis ma requete select, qui prend 1,6s.

-un deuxieme scénario dit "base déjà existante" avec juste une connexion à la base puis ma requete select, qui là prend 100 ms.

Des explications??