Bonjour,
 
j'ai un table SQL nommée "base" (assez volumineuse environ 50 millions de lignes) avec les champs suivants (tous INTEGER)  
 
pdv| ref | quantite | aa | mm | jj | ticket
 
sur laquelle j'effectue une sous-requête (une requête dans une requête) du genre :
 
SELECT ref, pdv, SUM(quantite) INTO OUTFILE "Fichier_resultat.csv" FROM base WHERE (ref=7891011 AND CONCAT(pdv,aa,mm,jj,ticket) IN (SELECT CONCAT(pdv,aa,mm,jj,ticket) FROM base WHERE ref=123456)) GROUP BY ref, pdv
 
le but : je recherche la somme des quantité par pdv sur la ref 7891011 lorsque celle ci comporte le même pdv, année (aa), mois (mm), jour (jj) et numéro de ticket (ticket) qu'une autre ref ici 12345
 
Mon problème : au bout d'une dizaine d'heure, la machine mouline toujours à plein régime processeur, et le fichier de résulat comporte exactement 0 ligne    
 
Ai-je fait une erreur de syntaxe ? La base est elle trop volumineuse ? Y'a t'il une déesse à invoquer ? Si oui laquelle ?
 
merci

Teste ta sous-requete à part pour voir le temps qu'elle met. Il serait de bon ton d'avoir un index sur ref aussi

quelle est la clé de ta table ?

la sous requête marche et fournit un résultat en un temps tt  à fait raisonnable.
 
Par contre je ne crois pas avoir de clé sur ma table (un index c'est ça ?).
 
ça se crée comment ?
 
merci

Faut voir dans la doc de ton sgbd ou avec l'admin de ta base si y'en a un.

Essaie ca, même si je doute que ce soit plus rapide...je pense que cette requête répond à tes besoins, mais ne pouvant la tester, il faudra en vérifier la logique, dans le cas peu probable ou tu aurais des résultats !
 
SELECT b1.pdv, b1.ref, SUM(b1.sumQuantite)
FROM  
(SELECT pdv, ref, SUM(quantite) AS sumQuantite, aa, mm, jj, ticket FROM base WHERE ref=7891011 GROUP BY pdv, ref, aa, mm, jj, ticket) b1,
(SELECT DISTINCT pdv, aa, mm, jj, ticket FROM base WHERE ref=123456) b2
WHERE b1.pdv=b2.pdv  
AND b1.aa=b2.aa  
AND b1.mm=b2.mm  
AND b1.jj=b2.jj  
AND b1.ticket=b2.ticket
GROUP BY b1.pdv, b1.ref
 
Et comme précisé plus haut, regarde tes clés et renseigne toi sur les indexs !

50 millions de ligne, si t'as pas d'index c'est de toute façon galère.

c'est clair, il faut que tu poses un index unique ou une clé primaire sinon c'est sûr ca va ramer sévère.
pour optimiser la requête, ce serait bien d'avoir la règle d'unicité des enregistrements aussi.
 
de plus pour la date je te conseille de gérer ca sur une colonne date et pas trois colonnes integer.
 

Salut, merci pour vos réponses.
 
j'aimerais bien creer un index, mais il me semble que ce n'est pas conseillee sur des champs qui contiennent des valeurs dupliquees, ce qui est le cas de tous les champs de ma base. Faut il que je cree une cle composite (par exemple en concatenant  : pdv + ref + aa + mm + jj + ticket) et que j'indexe dessus ?
 
pour ce qui est du format des date, j'en herite ainsi. ma table est issue de la fragmentation d'une chaine qui contient toutes les info listees.
 
 
a+

tu as deux types d'index : les index uniques et non uniques, tu peux donc très bien mettre un index même si tu as des valeurs redondantes dessus.
 
ce qui est important sur ta table c'est de connaître la règle d'unicité, c'est à dire ce qui caractérise ce qui fait que ton enregistrement est unique (pdv + ref + aa + mm + jj + ticket ?).
 
une fois cela déterminé, généralement rajouter un index unique en composite comme tu le dis, améliore la plupart des requêtes faites sur ta table.
 
une clé primaire si je ne dis pas de bétise, te permet d'avoir un index unique sur la table + la possibilité de gérer des contraintes d'intégrité référentielles sur les autres tables.
donc c'est intéressant si ta table est liée à d'autres tables sinon c'est facultatif.

 
Ok merci bcp
 
a+