Requête très lente

Bonjour,

la requête suivante (il y a un peu de php dedans):

Code:

---

1 2 3 4 5 6

$sql = "SELECT nom_pays, libelle_".$nomen.", sum(valeur) as valeur, sum(masse) as masse from pays as p , ".$impexp."_".$annee." as e, ".$nomen." as c where e.code_pays=p.code_pays and p.nom_pays = '".$pays."'". " and c.code_". $nomen ." = e.code_".$nomen." and libelle_".$nomen." = '".$produit."'";   $result = mysql_query($sql,$lien);

---

Me prend plusieurs seconde, quelle peut en être la cause?
Une des tables impliquées comporte environ 1,5 millions de lignes, les autres quelques centaines.

J'ai exécuté une requête de ce type directement au niveau du SGBD, et cela a pris 10 secondes. En réduisant la table d'un million de lignes à 10 lignes, cela a été immédiat. La taille de la table serait donc à mettre en cause. Ce qui, fort naïvement, me surprend un peu puisque j'avais cru que SQL servait justement à gagner du temps sur des choses de ce genre. Or un pote va infiniment plus vite en faisant la même chose juste avec python/csv...

Bonjour,

Pour expliquer les (contre-)performances d'une requête, il faut avant tout vérifier si les prédicats de filtrage (where) et de jointure (join) sont sargables ; c'est à dire s'il existe des index éligibles pour ces prédicats.
Comme vous n'avez communiqué ni la description des tables ni celle des index éventuels, il est impossible de vous aider.
Communiquez le DDL complet des tables et index, c'est à dire le script CREATE TABLE et CREATE INDEX pour tous les objets concernés par votre requête.
Précisez également le type exact de chacune des host variables, car une host-variable d'un mauvais type compromet l'utilisation des index.

Je vous invite à formuler les critères de jointures au moyen de l'opérateur JOIN comme le propose la norme SQL depuis plus de 20 ans.
Vos requêtes seront plus faciles à lire et à maintenir ;)

Bonjour escartefigue,

création de la table "e":

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

$sql = "CREATE TABLE export_2018 (" . " `idExport` int NOT NULL," . " `mois` int NOT NULL," . " `code_CPF6` varchar(9) NOT NULL," . " `code_A129` varchar(4) NOT NULL," . " `code_NC8` int NOT NULL," . " `code_pays` varchar(2) NOT NULL," . " `valeur` int NOT NULL," . " `masse` int NOT NULL," . " `usup` int NOT NULL," . " primary key(idExport))";

---

création de la table "p":

Code:

---

1 2 3 4 5

$sql = "CREATE TABLE `pays` (" . " `code_pays` varchar(2) NOT NULL," . " `nom_pays` varchar(100) NOT NULL," . " primary key (code_pays))";

---

création de la table "c":

Code:

---

1 2 3 4 5

$sql = "CREATE TABLE `A129` (" . " `code_A129` varchar(9) NOT NULL," . " `libelle_A129` varchar(1000) NOT NULL," . " primary key (code_A129))";

---

Citation:

---

Envoyé par esacrtefigue

Je vous invite à formuler les critères de jointures au moyen de l'opérateur JOIN comme le propose la norme SQL depuis plus de 20 ans.
Vos requêtes seront plus faciles à lire et à maintenir

---

J'ai eu un prof qui considérait que l'introduction de la formulation algébrique n'était pas tellement justifiée et qu'elle était moins claire. A vrai dire je suis d'accord, c'est pour cela que je ne l'utilise pas.

Il faudrait examiner la requête telle qu'elle est générée et non le code PHP, pour vérifier comment sont construites les jointures
Il est possible que les critères de jointures ne portent pas sur des colonnes de même type. Par exemple, dans la table pays, certains codes sont du varchar(2) d'autres varchar(4) ou encore de l'integer.

Si les types ou les longueurs utilisés en jointure sont différents, alors la requête est dite "non sargable" c'est à dire qu'aucun index n'est éligible.

Autre point non négligeable : vos pk portent sur des colonnes fonctionnelles, c'est une erreur à plusieurs titres.
Tout d'abord en terme de stabilité : si les valeurs de code changent, vous devrez mettre à jour toutes les tables qui possèdent ces codes. Ce sera lourd et couteux.
Ensuite en terme de performances : le varchar est ce qu'on fait de pire pour une PK, il est sensible à la collation, plus encombrant que de l'integer à nombre de valeurs possibles égal et il peut provoquer des déplacements de pages et data et index lors des mises à jour. De plus, pour certaines opérations (order by, group by, distinct), le varchar nécessite un alignement sur la longueur maxi.

Enfin, choisir du varchar pour une longueur de 2 est contre-performant comparativement à du char : il faut tenir compte de l'attribut longueur dont le char n'a pas besoin.

Citation:

---

Envoyé par Chezkele

J'ai eu un prof qui considérait que l'introduction de la formulation algébrique n'était pas tellement justifiée et qu'elle était moins claire. A vrai dire je suis d'accord, c'est pour cela que je ne l'utilise pas.

---

être d'accord avec un vieux con, c'est un peu limite ! L'opérateur JOIN est fait pour la jointure. La clause WHERE pour la restriction… Vous pouvez aussi utiliser un marteau pour enfoncer une vis… Mais un tournevis est plus adapté pour visser qu'un marteau !!!

Je suis toujours sidéré par la stupidité de certains professeurs qui ne se sont jamais recyclé ! C'est le triste sort de la France d'avoir des profs qui sont des fonctionnaires et ressassent le même cours pendant 40 ans, sans jamais se remettre en cause !

Pour apprendre SQL, mon livre :
https://www.amazon.fr/SQL-édition-Sy...ZKWHFTZH48GYB0


A +

Citation:

---

Envoyé par escartefigue

...De plus, pour certaines opérations (order by, group by, distinct), le varchar nécessite un alignement sur la longueur maxi.

---

Alignement, oui, longueur maxi, ça dépend des SGBDR… Pour MySQL je sais pas, mais je pense que oui (et en UTF8 ça fait très mal !). Pour SQL Server c'est la moitié…

A +

Salut SQLPRO.

Citation:

---

Envoyé par SQLPRO

Je suis toujours sidéré par la stupidité de certains professeurs qui ne se sont jamais recyclé ! C'est le triste sort de la France d'avoir des profs qui sont des fonctionnaires et ressassent le même cours pendant 40 ans, sans jamais se remettre en cause !

---

Sais-tu ce qu l'on dit au sujet des professeurs ?
S'il est professeur, c'est qu'il n'est pas capable de faire autre chose.
Ou si tu préfères, un professeur n'a aucune expérience du monde du travail !

Mais pourquoi se remettre en cause ?

Je prends l'exemple d'un professeur qui enseignait la mécanique.
(j'ai vu cela à la télé dans un reportage consacré, à juste titre à l'enseignement en France)
Tous ses élèves en sortant de l'école se retrouvent au chômage.
On lui demande alors pourquoi enseigne-t-il ?
Et il répond, pour ne pas se retrouver, lui aussi, au chômage.

Ce qu'on leur demande, c'est d'enseigner, pas de répondre au besoin du marché du travail !

@+

Citation:

---

Envoyé par Artemus24

Salut SQLPRO.


Sais-tu ce qu l'on dit au sujet des professeurs ?
S'il est professeur, c'est qu'il n'est pas capable de faire autre chose.
Ou si tu préfères, un professeur n'a aucune expérience du monde du travail !

---

Ce n'est heureusement pas le cas de tous les professeurs, loin s'en faut. Il en existe aussi et fort heureusement de très bons.
Notamment dans l'enseignement professionnel où certains professeurs sont aussi des entrepreneurs.

Pour rester dans le même thème, j'ai eu un professeur de mécanique retraité de l'armée de l'air (la retraite arrive tôt dans l'armée).
Et bien il était très bon. Il nous apprenait à diagnostiquer des pannes avec méthode et expliquait très bien, j'ai beaucoup aimé sa pédagogie et beaucoup appris grâce à lui, il donnait envie d'apprendre.
Je me souviens aussi d'un prof d'agronomie qui partageait ces mêmes qualités. Il avait toujours des anectodes vécues à faire partager, même les pires cancres l'écoutaient avec attention.

Salut Escartefigue.

Citation:

---

Envoyé par Escartefigue

Ce n'est heureusement pas le cas de tous les professeurs, loin s'en faut. Il en existe aussi et fort heureusement de très bons.

---

Oui, mais ils sont rares.

Pour ainsi dire, j'ai eu très peu de bons professeurs. Heureusement pour moi que j'aime apprendre car si j'avais compté sur eux, je n'aurai jamais été ingénieur.

@+