Bonjour, ptite question :
quand on fait une clef étrangère, il n'y a pas forcément d'index qui est
induit dans l'une des deux tables, il faut donc préciser les champs qui
doivent être indexés si ce ne sont pas des clefs primaires ?
NB : je suis dans mysql, mais je préfère une réponse générale :)
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
bruno modulix
Jean-Marc Molina wrote:
Pif a écrit/wrote :
quand on fait une clef étrangère, il n'y a pas forcément d'index qui est induit dans l'une des deux tables, il faut donc préciser les champs qui doivent être indexés si ce ne sont pas des clefs primaires ?
(snip)
Donc il te faut créer un index "manuellement". Et dans la majorité des cas je pense qu'il vaut mieux le faire car qui dit clé étrangère dit jointure un jour ou l'autre... et sans index ta jointure tu pourras l'attendre longtemps :).
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
nb: je suppose que le comportement du moteur de requête peut varier d'un SGBDR à l'autre...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Jean-Marc Molina wrote:
Pif a écrit/wrote :
quand on fait une clef étrangère, il n'y a pas forcément d'index qui
est induit dans l'une des deux tables, il faut donc préciser les
champs qui doivent être indexés si ce ne sont pas des clefs primaires
?
(snip)
Donc il te faut créer un index
"manuellement". Et dans la majorité des cas je pense qu'il vaut mieux le
faire car qui dit clé étrangère dit jointure un jour ou l'autre... et sans
index ta jointure tu pourras l'attendre longtemps :).
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ
insuffisamment discriminant pouvait s'avérer sérieusement
contre-productif, une recherche séquentielle simple nécessitant dans ce
cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant
pas pris le temps de tester la chose, je ne peux pas confirmer, mais
certains ici sauront peut-être ce qu'il en est en pratique ?
nb: je suppose que le comportement du moteur de requête peut varier d'un
SGBDR à l'autre...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
quand on fait une clef étrangère, il n'y a pas forcément d'index qui est induit dans l'une des deux tables, il faut donc préciser les champs qui doivent être indexés si ce ne sont pas des clefs primaires ?
(snip)
Donc il te faut créer un index "manuellement". Et dans la majorité des cas je pense qu'il vaut mieux le faire car qui dit clé étrangère dit jointure un jour ou l'autre... et sans index ta jointure tu pourras l'attendre longtemps :).
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
nb: je suppose que le comportement du moteur de requête peut varier d'un SGBDR à l'autre...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Fred Brouard - SQLpro
bruno modulix a écrit:
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
Vrai, dans la plupart des cas mais ussi dépend du volume des données. par exemple des valeurs "binaires" sont rarement indexées.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
Tout dépend le SGBDR. Certains comme SQL Server décident ou non de se servir de l'index en fontion de la dispersion des données et de l'étendeu de la plage de sélection. On considère en moyenne que le basculement se fait aux alentour de 10% de sélectivité. En deça => Index, au dessus => scan.
nb: je suppose que le comportement du moteur de requête peut varier d'un SGBDR à l'autre...
Exact !
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
bruno modulix a écrit:
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ
insuffisamment discriminant pouvait s'avérer sérieusement
contre-productif, une recherche séquentielle simple nécessitant dans ce
cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
Vrai, dans la plupart des cas mais ussi dépend du volume des données. par
exemple des valeurs "binaires" sont rarement indexées.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant
pas pris le temps de tester la chose, je ne peux pas confirmer, mais
certains ici sauront peut-être ce qu'il en est en pratique ?
Tout dépend le SGBDR. Certains comme SQL Server décident ou non de se servir de
l'index en fontion de la dispersion des données et de l'étendeu de la plage de
sélection.
On considère en moyenne que le basculement se fait aux alentour de 10% de
sélectivité. En deça => Index, au dessus => scan.
nb: je suppose que le comportement du moteur de requête peut varier d'un
SGBDR à l'autre...
Exact !
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
Vrai, dans la plupart des cas mais ussi dépend du volume des données. par exemple des valeurs "binaires" sont rarement indexées.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
Tout dépend le SGBDR. Certains comme SQL Server décident ou non de se servir de l'index en fontion de la dispersion des données et de l'étendeu de la plage de sélection. On considère en moyenne que le basculement se fait aux alentour de 10% de sélectivité. En deça => Index, au dessus => scan.
nb: je suppose que le comportement du moteur de requête peut varier d'un SGBDR à l'autre...
Exact !
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Patrick Mevzek
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que, si on utilise l'index, on doit encore après aller chercher les données (l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données pertinentes). S'il y a beaucoup de données à récupérer, on passera moins de temps à les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui ne va pas, que d'abord de lire l'index, puis d'aller chercher les données en ordre dispersé (l'accès aléatoire est plus lent que l'accès séquentiel).
Pour le mêmes raisons, un index n'est pas utilisé sur une table ``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan d'exécution et de savoir notamment si le SGBDR utilise un index ou non. Son interprétation est cependant souvent complexe, et de toute façon spécifique à un SGBDR. Mais vous pouvez faire des tests rapides, et voir que le plan change selon le contenu de la table. Il faut penser à mettre les données statistiques à jour, avec la commande ANALYZE. Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus fréquentes et leur répartition. On peut jouer sur la quantité de statistiques à prendre en compte. Une des évolutions prévues est de faire des statistiques de corrélation cette fois entre valeurs dans différents attributs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ
insuffisamment discriminant pouvait s'avérer sérieusement
contre-productif, une recherche séquentielle simple nécessitant dans ce
cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant
pas pris le temps de tester la chose, je ne peux pas confirmer, mais
certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que,
si on utilise l'index, on doit encore après aller chercher les données
(l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données
pertinentes).
S'il y a beaucoup de données à récupérer, on passera moins de temps à
les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui
ne va pas, que d'abord de lire l'index, puis d'aller chercher les données
en ordre dispersé (l'accès aléatoire est plus lent que l'accès
séquentiel).
Pour le mêmes raisons, un index n'est pas utilisé sur une table
``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan
d'exécution et de savoir notamment si le SGBDR utilise un index ou non.
Son interprétation est cependant souvent complexe, et de toute façon
spécifique à un SGBDR.
Mais vous pouvez faire des tests rapides, et voir que le plan change selon
le contenu de la table.
Il faut penser à mettre les données statistiques à jour, avec la
commande ANALYZE.
Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus
fréquentes et leur répartition. On peut jouer sur la quantité de
statistiques à prendre en compte. Une des évolutions prévues est de
faire des statistiques de corrélation cette fois entre valeurs dans
différents attributs.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que, si on utilise l'index, on doit encore après aller chercher les données (l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données pertinentes). S'il y a beaucoup de données à récupérer, on passera moins de temps à les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui ne va pas, que d'abord de lire l'index, puis d'aller chercher les données en ordre dispersé (l'accès aléatoire est plus lent que l'accès séquentiel).
Pour le mêmes raisons, un index n'est pas utilisé sur une table ``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan d'exécution et de savoir notamment si le SGBDR utilise un index ou non. Son interprétation est cependant souvent complexe, et de toute façon spécifique à un SGBDR. Mais vous pouvez faire des tests rapides, et voir que le plan change selon le contenu de la table. Il faut penser à mettre les données statistiques à jour, avec la commande ANALYZE. Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus fréquentes et leur répartition. On peut jouer sur la quantité de statistiques à prendre en compte. Une des évolutions prévues est de faire des statistiques de corrélation cette fois entre valeurs dans différents attributs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
bruno modulix
Patrick Mevzek wrote:
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que, si on utilise l'index, on doit encore après aller chercher les données (l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données pertinentes). S'il y a beaucoup de données à récupérer, on passera moins de temps à les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui ne va pas, que d'abord de lire l'index, puis d'aller chercher les données en ordre dispersé (l'accès aléatoire est plus lent que l'accès séquentiel).
Oui, c'est ce que m'avait expliqué le gars en question.
Pour le mêmes raisons, un index n'est pas utilisé sur une table ``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan d'exécution et de savoir notamment si le SGBDR utilise un index ou non. Son interprétation est cependant souvent complexe, et de toute façon spécifique à un SGBDR. Mais vous pouvez faire des tests rapides, et voir que le plan change selon le contenu de la table. Il faut penser à mettre les données statistiques à jour, avec la commande ANALYZE. Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus fréquentes et leur répartition. On peut jouer sur la quantité de statistiques à prendre en compte. Une des évolutions prévues est de faire des statistiques de corrélation cette fois entre valeurs dans différents attributs.
N'étant qu'un humble développeur, je laisse ce genre de soucis aux DBA !-) Pour ma part, j'ai de plus en plus tendance à adopter la stratégie du "less is better", bref à ne mettre en place que le minimum vital, et à voir après à l'usage...
Merci à toi et à Fred "SQLPro" pour vos explications...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Patrick Mevzek wrote:
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ
insuffisamment discriminant pouvait s'avérer sérieusement
contre-productif, une recherche séquentielle simple nécessitant dans ce
cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant
pas pris le temps de tester la chose, je ne peux pas confirmer, mais
certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que,
si on utilise l'index, on doit encore après aller chercher les données
(l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données
pertinentes).
S'il y a beaucoup de données à récupérer, on passera moins de temps à
les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui
ne va pas, que d'abord de lire l'index, puis d'aller chercher les données
en ordre dispersé (l'accès aléatoire est plus lent que l'accès
séquentiel).
Oui, c'est ce que m'avait expliqué le gars en question.
Pour le mêmes raisons, un index n'est pas utilisé sur une table
``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan
d'exécution et de savoir notamment si le SGBDR utilise un index ou non.
Son interprétation est cependant souvent complexe, et de toute façon
spécifique à un SGBDR.
Mais vous pouvez faire des tests rapides, et voir que le plan change selon
le contenu de la table.
Il faut penser à mettre les données statistiques à jour, avec la
commande ANALYZE.
Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus
fréquentes et leur répartition. On peut jouer sur la quantité de
statistiques à prendre en compte. Une des évolutions prévues est de
faire des statistiques de corrélation cette fois entre valeurs dans
différents attributs.
N'étant qu'un humble développeur, je laisse ce genre de soucis aux DBA
!-) Pour ma part, j'ai de plus en plus tendance à adopter la stratégie
du "less is better", bref à ne mettre en place que le minimum vital, et
à voir après à l'usage...
Merci à toi et à Fred "SQLPro" pour vos explications...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Le Wed, 31 Aug 2005 12:42:49 +0200, bruno modulix a écrit :
Mmm... Un DBA m'expliquait l'autre jour que mettre un index sur un champ insuffisamment discriminant pouvait s'avérer sérieusement contre-productif, une recherche séquentielle simple nécessitant dans ce cas (et en moyenne) bien moins d'accès disque que le passage par l'index.
N'étant pas moi-même gourou dans ce domaine, loin s'en faut, et n'ayant pas pris le temps de tester la chose, je ne peux pas confirmer, mais certains ici sauront peut-être ce qu'il en est en pratique ?
C'est exact, et cela s'explique souvent (ex: PostgreSQL) par le fait que, si on utilise l'index, on doit encore après aller chercher les données (l'index n'est qu'un ``pointeur'' pour retrouver rapidement les données pertinentes). S'il y a beaucoup de données à récupérer, on passera moins de temps à les lire toutes (accès séquentiels) et éliminer au fil de l'eau ce qui ne va pas, que d'abord de lire l'index, puis d'aller chercher les données en ordre dispersé (l'accès aléatoire est plus lent que l'accès séquentiel).
Oui, c'est ce que m'avait expliqué le gars en question.
Pour le mêmes raisons, un index n'est pas utilisé sur une table ``petite'', on va dire de moins de quelques milliers de lignes.
La commande EXPLAIN placée devant un ordre SQL permet d'avoir le plan d'exécution et de savoir notamment si le SGBDR utilise un index ou non. Son interprétation est cependant souvent complexe, et de toute façon spécifique à un SGBDR. Mais vous pouvez faire des tests rapides, et voir que le plan change selon le contenu de la table. Il faut penser à mettre les données statistiques à jour, avec la commande ANALYZE. Par exemple PostgreSQL stocke pour chaque attribut les valeurs les plus fréquentes et leur répartition. On peut jouer sur la quantité de statistiques à prendre en compte. Une des évolutions prévues est de faire des statistiques de corrélation cette fois entre valeurs dans différents attributs.
N'étant qu'un humble développeur, je laisse ce genre de soucis aux DBA !-) Pour ma part, j'ai de plus en plus tendance à adopter la stratégie du "less is better", bref à ne mettre en place que le minimum vital, et à voir après à l'usage...
Merci à toi et à Fred "SQLPro" pour vos explications...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
