Forum Clubic

Requête interminable

Bonjour à tous.
J’ai un problème avec une requête que j’essaye d’exécuter.
Voici la forme de cette requête :

SELECT t1.col1,t2.col1,t1.col2,t2.col2
FROM TABLE1 t1, TABLE2 t2
WHERE t1.col2=t2.col2 ;

où t1.col1 et t2.col1 sont clés primaires de mes tables TABLE1 et TABLE2
Ces deux tables comportent une 20aine de champs chacunes et contiennent environ 20000 lignes chacunes.
Lorsque je lance cette requête ( dans n’importe quel client mysql ), je n’ai ni message d’erreur ni un quelconque résultat, mais un temps d’attente interminable.
Quelqu’un sait-il si çà vient de ma requête? de la taille de mes tables ? de mon client (ou serveur) mysql ?
J’attend vos réponse avec impatience et vous remercie par avance de votre aide.
PS : serveur mysql version 4.1.11-max

Salut,

Il y a peut-être une erreur de syntaxe dans la requête (dans ce cas il est étonnant que MySQL n’ait rien dit). Cela concerne tes alias de tables. En effet pour MySQL j’ai toujours vu et utilisé la syntaxe suivante :
TABLE1 AS t1, TABLE2 AS t2

Bon courage.

Sinon pas très utile de récupérer t1.col2 ET t2.col2 si tu recherches les valeurs pour lesquelles t1.col2 = t2.col2 :wink:

crée un INDEX sur col1 de tes 2 tables peut-etre

Tout à fait d’accord avec toi, c’est rectifié…

Je vais paraitre bête, mais je n’ai jamais utilisé d’index… çà sert à quoi et comment çà marche?

Pour les alias, je vais vérifier çà de suite.

Merci

va regarder ça : http://sql.developpez.com/sqlaz/ddl/?page=partie2#L10

Saluton,
AS pour les alias est optionnel
Peut-être, outre la création d’index sur t1.col2=t2.col2, devrais-tu essayer de faire une vraie jointure :
SELECT t1.col1,t2.col1,t1.col2,t2.col2
FROM TABLE1 t1
JOIN TABLE2 t2 ON t1.col2=t2.col2
WHERE t2.col2 IS NOT NULL;

Merci beaucoup pour vos réponses, j’ai enfin résolu mon problème!
A partir du moment où j’ai rajouté des index (j’en ai mis partout, ce sont des tables temporaires), ma requête s’effectue en quelques secondes.
Je ne les avais jamais utilisés, mais çà marche super bien en tout cas !!!

Encore merci à tous :smiley:

bein oui comme c’est expliqué, avec des index en théorie tu as un gain de vitesse quadratique, ce qui n’est pas negligeable.

un index ca prend quoi comme ressource ?

parceque si c’était la solution miracle y en aurai partout ! qu’est ce qu’on perd avec un index qui justifie de n’en mettre que là ou y en a besoin ?

mais par defaut si tu regarde bien, il y a des index par defaut
sur al cle primaire, et sur les cles etrangere. Mais cela correspond pas forcement a tes besoins.

A savoir qu’un index mal fait, peut ralentir tes requetes :stuck_out_tongue:

D’après ce que j’ai pu voir, les index prennent de la mémoire, mais dans mon cas, comme ce sont des tables temporaires, çà ne me pose pas de pb…

bein en general quand tu fait de la bdd, tu as pas 16 mo de ram en edo :stuck_out_tongue:

Et puis il faut choisir, et faire un compromis entre performance et cout, mais aux vues du prix de la ram actuellement je crois que le choix est vite fait.

Puis ton index oui va bouffer un peu de ram, mais parcourir toute la table pour rien va en manger tout autant sinon +

encore une fois c’est un choix a faire.

L’indexation des tables de bases de données présentent un avantage indéniable lors des requêtes de sélection, jointures etc…
Cet avantage se paye lors des opérations de mise à jour, insertion et suppression.
Il se paye aussi en termes de volume de la base de données.
Il faut donc trouver le bon compromis en fonction des fréquences de mise à jour, et ce n’est jamais évident.

Si ç’avait vraiment été le cas, tu n’aurais pas eu de problème, vu qu’une clé primaire est tout bêtement un index unique…

C’est le cas, mais il n’y avait pas d’index sur les col2, et comme je mets une contrainte dessus, c’est çà qui bloquait…

Oh punaise j’ai lu / répondu trop vite, en effet col1 != col2 :smiley:
Désolé pour la bourde.