Discussion :

[papa6]

Bonjour,

J'ai un update sur plusieurs tables qui marche sur 2 ou 3 tables liées, mais dès que je les passe à 10 ou 15 tables, avec seulement 500 enregistrements sur la table principale, j'obtiens une erreur :

Code :

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

Erreur : The table '' is full

Est-ce normal ?
Voilà ce que me donne un explain de ma requête (j'ai remplacé le Update par Select pour obtenir l'Explain) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
EXPLAIN SELECT t1 . *
FROM `demo_art` AS t1
LEFT JOIN `demo_ach_det` AS t2 ON t2.`id_art` = t1.`cle_art`
LEFT JOIN `demo_art_lk` AS t3 ON t3.`id_art` = t1.`cle_art`
LEFT JOIN `demo_art_lk` AS t4 ON t4.`id_art_cible` = t1.`cle_art`
LEFT JOIN `demo_art_top` AS t5 ON t5.`id_art` = t1.`cle_art`
LEFT JOIN `demo_cde_det` AS t6 ON t6.`id_art` = t1.`cle_art`
LEFT JOIN `demo_fact_det_base` AS t7 ON t7.`id_art` = t1.`cle_art`
LEFT JOIN `demo_fact_part_det` AS t8 ON t8.`id_art` = t1.`cle_art`
LEFT JOIN `demo_parc_obso` AS t9 ON t9.`id_art` = t1.`cle_art`
LEFT JOIN `demo_propale_det` AS t10 ON t10.`id_art` = t1.`cle_art`
LEFT JOIN `demo_stk_det` AS t11 ON t11.`id_art` = t1.`cle_art`
LEFT JOIN `demo_entr_art_interdits` AS t12 ON t12.`id_art` = t1.`cle_art`

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
1 	SIMPLE 	t1 	ALL 	NULL 	NULL 	NULL 	NULL 	602 	 
1 	SIMPLE 	t2 	ref 	id_art 	id_art 	3 	t1.cle_art 	1 	Using index
1 	SIMPLE 	t3 	ref 	id_art 	id_art 	3 	t1.cle_art 	1 	Using index
1 	SIMPLE 	t4 	ref 	id_art_cible 	id_art_cible 	3 	t1.cle_art 	1 	Using index
1 	SIMPLE 	t5 	ref 	id_art 	id_art 	3 	t1.cle_art 	4 	Using index
1 	SIMPLE 	t6 	ref 	id_art 	id_art 	3 	t1.cle_art 	13 	Using index
1 	SIMPLE 	t7 	ref 	id_art 	id_art 	3 	t1.cle_art 	11 	Using index
1 	SIMPLE 	t8 	ref 	id_art 	id_art 	3 	t1.cle_art 	10 	Using index
1 	SIMPLE 	t9 	ref 	id_art 	id_art 	3 	t1.cle_art 	4 	Using index
1 	SIMPLE 	t10 	ref 	id_art 	id_art 	3 	t1.cle_art 	1 	Using index
1 	SIMPLE 	t11 	ref 	id_art 	id_art 	3 	t1.cle_art 	1 	Using index
1 	SIMPLE 	t12 	ref 	id_art 	id_art 	3 	t1.cle_art 	9 	Using index

Vous pouvez voir que j'ai bien défini mes jointures, mes index, notamment les "rows" qui ne sont pas abusives.

J'ai également lancé :

Code :

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

1
2
$res_tmp = mysql_query("SET BIG_TABLES=1");
$res_tmp = mysql_query("SET OPTION SQL_BIG_SELECTS=1");

Ce qui m'étonne, c'est comme je le disais plus haut, d'avoir ce message pour seulement 500 entrées dans ma table principale, alors que je pensais que ce genre d'erreurs viendrait avec 50.000 ou 100.000 enregistrements.

Est-ce que quelqu'un aurait une idée ?
Merci à vous

[Maljuna Kris]

Saluton,
je pense que le SELECT * est en partie responsable de l'inutile encombrement de la mémoire.
http://www.expreg.com/fred_article.p...re_des_etoiles
Mais je ne serais pas honnête si je masquais ma curiosité de connaître le schéma conceptuel qui nécessite cette requête avec un 15zaine de tables en jointure.

[papa6]

Bonjour,

Moi non plus j'ai horreur du SELECT * ! Mais je l'ai écrit rapidement pour pouvoir afficher le "EXPLAIN" : la vraie requête qui pose problème est un Update sur tables multiples.

Mais je ne serais pas honnête si je masquais ma curiosité de connaître le schéma conceptuel qui nécessite cette requête avec un 15zaine de tables en jointure.

Je développe un service de suivi commercial (chefdesventes, qu'on y mette un .org pour la prog' ou .fr pour la vente du service).
Pour les articles, comme pour les entreprises, ce sont des données qui intègrent des sous-rubriques, et qui ne font pas beaucoup appel à des créations de nouvel article ou nouvelle entreprise. J'ai donc choisi une structure avec une "arborescence par intervalles" : http://sqlpro.developpez.com/cours/arborescence/

Et donc, dès qu'il y a une modification dans l'ordre des articles, ce sont toutes les tables de propales, contrats, factures, stock, mais aussi diverses données sur les articles, qui sont mises à jour.
Pour les sociétés, ça doit tourner entre 5 et 10 tables ("seulement").
Voilà voilà...

[Sivrît]

Ce qui m'étonne, c'est comme je le disais plus haut, d'avoir ce message pour seulement 500 entrées dans ma table principale, alors que je pensais que ce genre d'erreurs viendrait avec 50.000 ou 100.000 enregistrements.

Oh, mais il y a bien plus de 500 éléments. Il ne faut pas oublier que le jointures croisent leurs résultats, et ici il y en a un paquet, donc ça monte vite.

D'après les estimations de MySQL (c'est approximatif, mais il est même possible qu'il sous-estime de beaucoup), le résultat va contenir dans les 602*3*4*13*11*10*4*9 = 371 891 520 valeurs. Je suppose que c'est trop pour le serveur, surtout si "demo_art" est une table "large".

[papa6]

Bonjour,
et merci Sivrît

Ben oui, malheureusement tu as raison... C'est trop gros (et en plus, je n'en suis qu'à la phase de tests, et non de pleine utilisation )

La solution que j'utilise donc :
Une série d'Updates

Ce n'est pas le plus rigoureux, car j'aimais bien les mises à jour simultanées par l'update sur des tables multiples, mais c'est ce qui marche.

Durant ces opérations délicates, je crains des interruptions du serveur pour une raison x ou y, et que certains champs soient à jour, et d'autres non. Je stocke donc mes requêtes dans une table, que j'exécute d'une traite. Si certaines requêtes ne sont pas exécutées, alors je le verrais (mais "bonjour" pour corriger ensuite).

Voilà voilà, sujet en grande partie résolu

[Sivrît]

Durant ces opérations délicates, je crains des interruptions du serveur pour une raison x ou y, et que certains champs soient à jour, et d'autres non. Je stocke donc mes requêtes dans une table, que j'exécute d'une traite. Si certaines requêtes ne sont pas exécutées, alors je le verrais (mais "bonjour" pour corriger ensuite).

Normalement, la solution à ça devrait être d'utiliser un moteur transactionnel (bref InnoDb) et de regrouper les opération critiques / liées dans une même transaction.