Précédent   Forum des professionnels en informatique > Bases de données > Sybase > Adaptive Server Enterprise
Adaptive Server Enterprise Forum d'entraide concernant Sybase Adaptive Server Enterprise, le dataserver phare de Sybase
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 08/03/2011, 11h41   #1
Invité régulier
 
Étudiant
Inscription : juillet 2006
Messages : 42
Détails du profil
Informations professionnelles :
Activité : Étudiant

Informations forums :
Inscription : juillet 2006
Messages : 42
Points : 9
Points : 9
Par défaut Jointure sur un index à deux colonnes

Bonjour à tous,

Je rencontre un souci dans une requête SQL (lenteurs).

J'ai une table volumineuse appelant la "table_resultat" ayant deux index comme suit :

Code :
1
2
3
 
CREATE  NONCLUSTERED INDEX idx1 ON table_resultat (A,B)
CREATE  CLUSTERED INDEX      idx2 ON table_resultat (B,A)
J'ai une autre table appelant table_status moins volumineuse que la tale table_resultat.

Je souhaite faire une jointure entre ces deux tables la, on exploitant l'un des deux index cités précédemment.

Dans un premier temps j'ai cette requête :

Code :
1
2
3
4
5
SELECT count(*)
  FROM table_resultat R
  JOIN LIMIT_table_status S
  ON R.A=S.A
AND R.B=S.B
D'après le plan d'exécution, il me semble qu’il n’exploite pas l'index.

Y a-t-il moyen de le forcer à utilise l'index ?

Merci pour votre retour .

Cordialement,
hbellahc.
hbellahc est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 09/03/2011, 13h23   #2
Rédacteur/Modérateur
 
Inscription : janvier 2006
Messages : 1 300
Détails du profil
Informations personnelles :
Âge : 52

Informations forums :
Inscription : janvier 2006
Messages : 1 300
Points : 1 504
Points : 1 504
Envoyer un message via AIM à mpeppler
Le forçage d'index ce fait comme ceci:

Code :
1
2
3
4
5
6
 
SELECT count(*)
  FROM table_resultat R (INDEX idx1)
  JOIN LIMIT_table_status S 
  ON R.A=S.A
AND R.B=S.B
La non-utilisation de l'index est en général causé par des statistiques qui ne sont pas à jour.

Michael
__________________
Michael Peppler
Membre de TeamSybase - www.teamsybase.com

"A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson
mpeppler est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 09/03/2011, 22h12   #3
Nouveau Membre du Club
 
Inscription : décembre 2007
Messages : 26
Détails du profil
Informations personnelles :
Localisation : France

Informations forums :
Inscription : décembre 2007
Messages : 26
Points : 30
Points : 30
Citation:
La non-utilisation de l'index est en général causé par des statistiques qui ne sont pas à jour.
Il est aussi possible que l'optimiseur considère (calcul) qu'un "table scan" sera moins couteux ...

Les index "idx1" et "idx2" ne sont pas unique ? c'est juste un oubli/simplification de l'exemple ou est-ce voulu ? (le couple "A" + "B" est-il unique ?)


DBRep
DBRep est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 10/03/2011, 12h45   #4
Rédacteur
 
Avatar de Arnaud F.
 
Homme Arnaud Feltz
Développeur .NET
Inscription : août 2005
Messages : 5 204
Détails du profil
Informations personnelles :
Nom : Homme Arnaud Feltz
Âge : 25
Localisation : France

Informations professionnelles :
Activité : Développeur .NET
Secteur : Transports

Informations forums :
Inscription : août 2005
Messages : 5 204
Points : 6 113
Points : 6 113
Citation:
Envoyé par DBRep Voir le message
Les index "idx1" et "idx2" ne sont pas unique ? c'est juste un oubli/simplification de l'exemple ou est-ce voulu ? (le couple "A" + "B" est-il unique ?)
C'est sûrement dû au fait que Sybase n'autorise qu'un seul index Cluster par table (et quand on comprend ce que fais un index clustered, cette limite paraît évidente).

D'ou un cluster et l'autre non
__________________
C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

Installation de Code::Blocks sous Debian à partir de Nightly Builds
Arnaud F. est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 10/03/2011, 14h00   #5
Rédacteur/Modérateur
 
Inscription : janvier 2006
Messages : 1 300
Détails du profil
Informations personnelles :
Âge : 52

Informations forums :
Inscription : janvier 2006
Messages : 1 300
Points : 1 504
Points : 1 504
Envoyer un message via AIM à mpeppler
Mais le fait d'être "cluster" n'a rien à voir avec l'unicité...

"clustered" est utile en cas de query "range" (en tout cas pour des tables APL) - difficile de dire dans le cas précis si le cluster est utile ou non sans connaitre le contenu de la table qui limite l'ensemble des lignes qui qualifies la query.

Michael
__________________
Michael Peppler
Membre de TeamSybase - www.teamsybase.com

"A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson
mpeppler est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 10/03/2011, 19h15   #6
Nouveau Membre du Club
 
Inscription : décembre 2007
Messages : 26
Détails du profil
Informations personnelles :
Localisation : France

Informations forums :
Inscription : décembre 2007
Messages : 26
Points : 30
Points : 30
Citation:
Mais le fait d'être "cluster" n'a rien à voir avec l'unicité...
Tu m'enlèves les mots du clavier

Ceci dit, je pense qu'un index "unique" doit aider l'optimiseur dans son choix ..



DBRep
DBRep est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 16h21.


 
 
 
 
Partenaires

Hébergement Web