T-SQL : Sens de jointure plus rapide qu'un autre ?
4 réponses
Jean-Yves
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et
la moins pénalisante en matière de ressources, sachant que A pèse 29 millions
d'enregistrements et B entre 1 et 100 et que A est indexé avec une
sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx)
2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais...
Merci.
Jean-Yves
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
lionelp
Bonjour,
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que des index et statistiques de chaque table quelle est le meilleur ordre de jointure.
"Jean-Yves" wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et la moins pénalisante en matière de ressources, sachant que A pèse 29 millions d'enregistrements et B entre 1 et 100 et que A est indexé avec une sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais... Merci. Jean-Yves
Bonjour,
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est
capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que
des index et statistiques de chaque table quelle est le meilleur ordre de
jointure.
"Jean-Yves" wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et
la moins pénalisante en matière de ressources, sachant que A pèse 29 millions
d'enregistrements et B entre 1 et 100 et que A est indexé avec une
sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx)
2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais...
Merci.
Jean-Yves
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que des index et statistiques de chaque table quelle est le meilleur ordre de jointure.
"Jean-Yves" wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et la moins pénalisante en matière de ressources, sachant que A pèse 29 millions d'enregistrements et B entre 1 et 100 et que A est indexé avec une sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais... Merci. Jean-Yves
Steve Kass
Jean-Yves,
Au cas qu'il y a plusieurs tables et plusiers indexes, l'optimisateur ne peut pas considérer tous les plans, et l'ordre peut déterminer si un plan rapide est considéré ou non. J'ai vu cette difference dans les réquetes comme
select T.a, T.b, min(U.c) as c from ( select a, min(b) as b from T1, T2 where ... group by a ) T join U on T.a = U.a group by T.a, T.b
versus
select T.a, T.b, min(U.c) as c from U join ( select a, min(b) as b from T1, T2 where ... group by a ) T on T.a = U.a group by T.b, T.a
Steve Kass Drew University
Jean-Yves wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et la moins pénalisante en matière de ressources, sachant que A pèse 29 millions d'enregistrements et B entre 1 et 100 et que A est indexé avec une sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais... Merci. Jean-Yves
Jean-Yves,
Au cas qu'il y a plusieurs tables et plusiers indexes, l'optimisateur
ne peut pas considérer tous les plans, et l'ordre peut déterminer
si un plan rapide est considéré ou non. J'ai vu cette difference
dans les réquetes comme
select T.a, T.b, min(U.c) as c
from (
select a, min(b) as b
from T1, T2
where ...
group by a
) T join U
on T.a = U.a
group by T.a, T.b
versus
select T.a, T.b, min(U.c) as c
from U join (
select a, min(b) as b
from T1, T2
where ...
group by a
) T
on T.a = U.a
group by T.b, T.a
Steve Kass
Drew University
Jean-Yves wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et
la moins pénalisante en matière de ressources, sachant que A pèse 29 millions
d'enregistrements et B entre 1 et 100 et que A est indexé avec une
sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx)
2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais...
Merci.
Jean-Yves
Au cas qu'il y a plusieurs tables et plusiers indexes, l'optimisateur ne peut pas considérer tous les plans, et l'ordre peut déterminer si un plan rapide est considéré ou non. J'ai vu cette difference dans les réquetes comme
select T.a, T.b, min(U.c) as c from ( select a, min(b) as b from T1, T2 where ... group by a ) T join U on T.a = U.a group by T.a, T.b
versus
select T.a, T.b, min(U.c) as c from U join ( select a, min(b) as b from T1, T2 where ... group by a ) T on T.a = U.a group by T.b, T.a
Steve Kass Drew University
Jean-Yves wrote:
Bonjour,
J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et la moins pénalisante en matière de ressources, sachant que A pèse 29 millions d'enregistrements et B entre 1 et 100 et que A est indexé avec une sélectivité bonne à excellente ?
1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
J'aurais tendance à dire la 2), mais... Merci. Jean-Yves
Jean-Yves
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique à mon exemple, parce que - plan à l'appui - il essaie de passer par un autre index, qu'il utilise de façon fragmentaire, ce qui donne un table scan hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé, bien plus restreint ?
L'o pô compris... Jean-Yves "" a écrit :
Bonjour,
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que des index et statistiques de chaque table quelle est le meilleur ordre de jointure.
"Jean-Yves" wrote:
> Bonjour, > > J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et > la moins pénalisante en matière de ressources, sachant que A pèse 29 millions > d'enregistrements et B entre 1 et 100 et que A est indexé avec une > sélectivité bonne à excellente ? > > 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) > 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx) > > J'aurais tendance à dire la 2), mais... > Merci. > Jean-Yves
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique à
mon exemple, parce que - plan à l'appui - il essaie de passer par un autre
index, qu'il utilise de façon fragmentaire, ce qui donne un table scan
hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé, bien
plus restreint ?
L'o pô compris...
Jean-Yves
"lionelp@online.microsoft.com" a écrit :
Bonjour,
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est
capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que
des index et statistiques de chaque table quelle est le meilleur ordre de
jointure.
"Jean-Yves" wrote:
> Bonjour,
>
> J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et
> la moins pénalisante en matière de ressources, sachant que A pèse 29 millions
> d'enregistrements et B entre 1 et 100 et que A est indexé avec une
> sélectivité bonne à excellente ?
>
> 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx)
> 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
>
> J'aurais tendance à dire la 2), mais...
> Merci.
> Jean-Yves
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique à mon exemple, parce que - plan à l'appui - il essaie de passer par un autre index, qu'il utilise de façon fragmentaire, ce qui donne un table scan hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé, bien plus restreint ?
L'o pô compris... Jean-Yves "" a écrit :
Bonjour,
L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server est capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi que des index et statistiques de chaque table quelle est le meilleur ordre de jointure.
"Jean-Yves" wrote:
> Bonjour, > > J'ai un doute : des deux commandes suivantes, laquelle est la plus rapide et > la moins pénalisante en matière de ressources, sachant que A pèse 29 millions > d'enregistrements et B entre 1 et 100 et que A est indexé avec une > sélectivité bonne à excellente ? > > 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) > 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx) > > J'aurais tendance à dire la 2), mais... > Merci. > Jean-Yves
Philippe [MS]
Bonjour,
Peut-être qu'un sp_recompile de la procédure et un UPDATE STATISTICS des tables permettrai de ne plus être obligé de forcer l'index ?
Phil.
"Jean-Yves" wrote in message news:
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique
à
mon exemple, parce que - plan à l'appui - il essaie de passer par un autre index, qu'il utilise de façon fragmentaire, ce qui donne un table scan hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé,
bien
plus restreint ?
L'o pô compris... Jean-Yves "" a écrit :
> Bonjour, > > L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server
est
> capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi
que
> des index et statistiques de chaque table quelle est le meilleur ordre
de
> jointure. > > "Jean-Yves" wrote: > > > Bonjour, > > > > J'ai un doute : des deux commandes suivantes, laquelle est la plus
rapide et
> > la moins pénalisante en matière de ressources, sachant que A pèse 29
millions
> > d'enregistrements et B entre 1 et 100 et que A est indexé avec une > > sélectivité bonne à excellente ? > > > > 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) > > 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx) > > > > J'aurais tendance à dire la 2), mais... > > Merci. > > Jean-Yves
Bonjour,
Peut-être qu'un sp_recompile de la procédure et un UPDATE STATISTICS des
tables permettrai de ne plus être obligé de forcer l'index ?
Phil.
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:11173D64-2640-45BE-8AF1-66710FFD2B93@microsoft.com...
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique
à
mon exemple, parce que - plan à l'appui - il essaie de passer par un autre
index, qu'il utilise de façon fragmentaire, ce qui donne un table scan
hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé,
bien
plus restreint ?
L'o pô compris...
Jean-Yves
"lionelp@online.microsoft.com" a écrit :
> Bonjour,
>
> L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server
est
> capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi
que
> des index et statistiques de chaque table quelle est le meilleur ordre
de
> jointure.
>
> "Jean-Yves" wrote:
>
> > Bonjour,
> >
> > J'ai un doute : des deux commandes suivantes, laquelle est la plus
rapide et
> > la moins pénalisante en matière de ressources, sachant que A pèse 29
millions
> > d'enregistrements et B entre 1 et 100 et que A est indexé avec une
> > sélectivité bonne à excellente ?
> >
> > 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx)
> > 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx)
> >
> > J'aurais tendance à dire la 2), mais...
> > Merci.
> > Jean-Yves
Peut-être qu'un sp_recompile de la procédure et un UPDATE STATISTICS des tables permettrai de ne plus être obligé de forcer l'index ?
Phil.
"Jean-Yves" wrote in message news:
Alors pourquoi suis-je obligé de forcer l'index dans une requête identique
à
mon exemple, parce que - plan à l'appui - il essaie de passer par un autre index, qu'il utilise de façon fragmentaire, ce qui donne un table scan hyper-long (29M d'enregistrement) au lieu d'un accès séquentiel indexé,
bien
plus restreint ?
L'o pô compris... Jean-Yves "" a écrit :
> Bonjour, > > L'ordre de la jointure n'a pas d'importance quand on l'écrit, SQL Server
est
> capable d'évaluer à partir du nombre de lignes et nombre de pages ainsi
que
> des index et statistiques de chaque table quelle est le meilleur ordre
de
> jointure. > > "Jean-Yves" wrote: > > > Bonjour, > > > > J'ai un doute : des deux commandes suivantes, laquelle est la plus
rapide et
> > la moins pénalisante en matière de ressources, sachant que A pèse 29
millions
> > d'enregistrements et B entre 1 et 100 et que A est indexé avec une > > sélectivité bonne à excellente ? > > > > 1) SELECT A.xxx, A.yyy FROM A INNER JOIN B ON (B.xxx = A.xxx) > > 2) SELECT A.xxx, A.yyy FROM B INNER JOIN A ON (A.xxx = B.xxx) > > > > J'aurais tendance à dire la 2), mais... > > Merci. > > Jean-Yves
