Sur une base de 400 000 lignes, la requête suivante pose pb* :
SELECT DISTINCT no_client FROM Clients
WHERE no_client NOT IN ( SELECT DISTINCT no_client FROM Clients WHERE date
BETWEEN '2006-04-01 ' AND '2006-04-01 ')
ORDER BY no_client
Chaque requête prise séparément est cohérente, est un
SELECT DISTINCT no_client FROM Clients me retourne environ 2500 items.
Où est le pb à votre avis ?
Merci.
* ) temps de réponse trop long , plus de 5 mn, obligé d'annuler la requête
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pif
Patrick Mevzek a écrit :
Quand vous arrêterez d'être persuadé que vous atteignez de soi-disantes limites (avec 400000 tuples MDR !) intraséques au SGBDR/SQL, que vous êtes obligés de forcer un plan d'exécutation car vous êtes nécessairement meilleur dans sa réalisation que n'importe quel planificateur de n'importe quel SGBDR, et de connaître tous les SGBDRs, alors revenez ici et nous discuterons concrétement.
non, 400 000 c'était l'essai de la question originelle... comme j'ai dit, je fais de la fouille de données.. mes requetes à problème sont en général entre 15 et 150 millions de tuples... donc si on le met au carré, ca fait mal...
oui, la planification automatique pose problème, essentiellement (à mon avis) parce que l'utilisateur n'a pas suffisement d'information pour cela...
D'ici là, je m'arrêterai là pour ma part.
PS: les gens qui n'utilisent pas les transactions, c'est en général mauvais signe (même si elles ne sont pas obligatoires, elles sont souvent importantes voir indispensables, et si on ne l'utilise pas il faut comprendre *précisément* ce que cela signifie, ce qui, dans mon expérience, est très rare). Et signe encore une fois de MySQLitisme. Ca en aura fait des dégâts...
elle sont importantes si 1) on a des contraintes d'intégrité qui en valent la chandelle et donc des sections critiques 2) en général dans le cadre d'approche multi utilisateur (c'est pas mon cas, je fais de la fouille de donnée, le SGBDR est un outil de persistance locale pour l'instant...) 3) les systèmes gérant les transaction ont comme premiere caractéristique d'autoriser la désactivation temporaire des transactions pour certaines besoins particuliers...
--> je n'utilise pas de transaction car je n'ai pas de contraintes critique de reconstruction de données ou d'intégrité des mes données... si je perds un ou deux tuples par si par la dans mes 150 000 000 c'est pas bien grave... COmme vous l'avez dit, les transaction répondre à une besoin particulier, (certes très courant)
Je ne suis pas fan de MySQL... je lui fait de nombreux reproches, mais simplement pas sur les transactions (que je n'utilise pas, sinon, j'aurais très probablement d'autres reproches) ni sur les performances...
Patrick Mevzek a écrit :
Quand vous arrêterez d'être persuadé que vous atteignez de soi-disantes
limites (avec 400000 tuples MDR !) intraséques au SGBDR/SQL, que vous
êtes obligés de forcer un plan d'exécutation car vous êtes
nécessairement meilleur dans sa réalisation que n'importe quel
planificateur de n'importe quel SGBDR, et de connaître tous les SGBDRs,
alors revenez ici et nous discuterons concrétement.
non, 400 000 c'était l'essai de la question originelle... comme j'ai
dit, je fais de la fouille de données.. mes requetes à problème sont en
général entre 15 et 150 millions de tuples... donc si on le met au
carré, ca fait mal...
oui, la planification automatique pose problème, essentiellement (à mon
avis) parce que l'utilisateur n'a pas suffisement d'information pour
cela...
D'ici là, je m'arrêterai là pour ma part.
PS: les gens qui n'utilisent pas les transactions, c'est en général
mauvais signe (même si elles ne sont pas obligatoires, elles sont
souvent importantes voir indispensables, et si on ne l'utilise pas il
faut comprendre *précisément* ce que cela signifie, ce qui, dans mon
expérience, est très rare). Et signe encore une fois de MySQLitisme. Ca
en aura fait des dégâts...
elle sont importantes si
1) on a des contraintes d'intégrité qui en valent la chandelle et donc
des sections critiques
2) en général dans le cadre d'approche multi utilisateur (c'est pas mon
cas, je fais de la fouille de donnée, le SGBDR est un outil de
persistance locale pour l'instant...)
3) les systèmes gérant les transaction ont comme premiere
caractéristique d'autoriser la désactivation temporaire des transactions
pour certaines besoins particuliers...
--> je n'utilise pas de transaction car je n'ai pas de contraintes
critique de reconstruction de données ou d'intégrité des mes données...
si je perds un ou deux tuples par si par la dans mes 150 000 000 c'est
pas bien grave...
COmme vous l'avez dit, les transaction répondre à une besoin
particulier, (certes très courant)
Je ne suis pas fan de MySQL... je lui fait de nombreux reproches, mais
simplement pas sur les transactions (que je n'utilise pas, sinon,
j'aurais très probablement d'autres reproches) ni sur les performances...
Quand vous arrêterez d'être persuadé que vous atteignez de soi-disantes limites (avec 400000 tuples MDR !) intraséques au SGBDR/SQL, que vous êtes obligés de forcer un plan d'exécutation car vous êtes nécessairement meilleur dans sa réalisation que n'importe quel planificateur de n'importe quel SGBDR, et de connaître tous les SGBDRs, alors revenez ici et nous discuterons concrétement.
non, 400 000 c'était l'essai de la question originelle... comme j'ai dit, je fais de la fouille de données.. mes requetes à problème sont en général entre 15 et 150 millions de tuples... donc si on le met au carré, ca fait mal...
oui, la planification automatique pose problème, essentiellement (à mon avis) parce que l'utilisateur n'a pas suffisement d'information pour cela...
D'ici là, je m'arrêterai là pour ma part.
PS: les gens qui n'utilisent pas les transactions, c'est en général mauvais signe (même si elles ne sont pas obligatoires, elles sont souvent importantes voir indispensables, et si on ne l'utilise pas il faut comprendre *précisément* ce que cela signifie, ce qui, dans mon expérience, est très rare). Et signe encore une fois de MySQLitisme. Ca en aura fait des dégâts...
elle sont importantes si 1) on a des contraintes d'intégrité qui en valent la chandelle et donc des sections critiques 2) en général dans le cadre d'approche multi utilisateur (c'est pas mon cas, je fais de la fouille de donnée, le SGBDR est un outil de persistance locale pour l'instant...) 3) les systèmes gérant les transaction ont comme premiere caractéristique d'autoriser la désactivation temporaire des transactions pour certaines besoins particuliers...
--> je n'utilise pas de transaction car je n'ai pas de contraintes critique de reconstruction de données ou d'intégrité des mes données... si je perds un ou deux tuples par si par la dans mes 150 000 000 c'est pas bien grave... COmme vous l'avez dit, les transaction répondre à une besoin particulier, (certes très courant)
Je ne suis pas fan de MySQL... je lui fait de nombreux reproches, mais simplement pas sur les transactions (que je n'utilise pas, sinon, j'aurais très probablement d'autres reproches) ni sur les performances...
Pif
Patrick Mevzek a écrit :
Le Thu, 19 Oct 2006 14:41:20 +0200, Pif a écrit :
Mais oui, c'est ca... (bien sûr que si que le schéma a un impact sur les performances...)
personnellement, je préfère garder un bon schéma et réaliser moi meme le découpage de quelques requetes, que foutre un schéma en l'air pour des problèmes isolés de performance...
Vraiment n'importe quoi, donc je m'arrête là.
Patrick Mevzek a écrit :
Le Thu, 19 Oct 2006 14:41:20 +0200, Pif a écrit :
Mais oui, c'est ca...
(bien sûr que si que le schéma a un impact sur les performances...)
personnellement, je préfère garder un bon schéma et réaliser moi meme le
découpage de quelques requetes, que foutre un schéma en l'air pour des
problèmes isolés de performance...
Mais oui, c'est ca... (bien sûr que si que le schéma a un impact sur les performances...)
personnellement, je préfère garder un bon schéma et réaliser moi meme le découpage de quelques requetes, que foutre un schéma en l'air pour des problèmes isolés de performance...
Vraiment n'importe quoi, donc je m'arrête là.
mordicus
helios wrote:
"pose pb" c'est quoi ?
Il rapporte un problème qu'il rencontre, et demande conseil
"temps de réponse trop long , plus de 5 mn, obligé d'annuler la requête" c'est pas une plainte ?
Non
Donc on est bien d'accord, tu dis n'importe quoi
helios wrote:
"pose pb" c'est quoi ?
Il rapporte un problème qu'il rencontre, et demande conseil
"temps de réponse trop long , plus de 5 mn, obligé d'annuler la requête"
c'est pas une plainte ?
