2010-09-14 4 views
0

Nous avons une table avec deux index non clusterisés. Les deux indices ont tous les deux les mêmes trois colonnes, dans le même ordre ils ne diffèrent que par le fait que l'un est trié par ordre ascendant et l'autre descendant. Un développeur avait créé une procédure stockée qui faisait un select où il voulait (mais a oublié!) Pour forcer l'utilisation d'un index plutôt que de faire un Order by. Lorsqu'un utilisateur exécute la requête, un index est toujours sélectionné (ironiquement le bon qui a masqué cette erreur pendant un certain temps), lorsqu'un autre utilisateur exécute la procédure, l'autre index est retourné. Qu'est-ce qui serait différent entre deux utilisateurs exécutant exactement la même procédure qui influencerait la sélection d'index? (Note: ce code sera réécrit, mais j'essaie de comprendre ce qui s'est passé ici pour un rapport après action).Sélection d'index non cluster Sybase

Merci à l'avance

Répondre

0

Les index sont peu plus complexes qu'ils ne paraissent. Un système de base de données décide d'utiliser l'index (ou non) en fonction du plan de requête, du volume de la table, du nombre de lignes, du cache de la base de données. Le système de base de données effectue une estimation des coûts (probabilité de cardinalité, estimations d'e/s, etc.) en fonction des requêtes et des données ci-dessus.

Si vous avez deux indices similaires avec différents systèmes de tri, il y a une chance que l'indice requis clé (i) est situé à près n/2n=index size

Il y a aussi une possibilité que basée sur les données (données dupliquées/les données sérielles) dans la table, sybase ne se soucie pas des index et ne peut donc pas décider lequel utiliser.

Supprimez un index à la fois et voyez ce qui se passe.

1

Vous n'avez pas spécifié quelle Sybase vous possédez. Je vais supposer ASE.

La sélection d'index dépend de plusieurs facteurs.

Compte tenu de votre cas, où le code n'a pas changé, et les deux utilisateurs utilisent la même procédure stockée, il y a deux possibilités:

  • vérifier que les statistiques sont à jour. Selon la façon dont votre administrateur de base de données a automatisé la fonction UPDATE STATISTICS et le niveau (soit le niveau de l'index ou de la table); un index pourrait être à jour et l'autre pourrait être périmé. Contrairement à l'optimiseur ASE 12.5.4, l'optimiseur ASE 15.x est sensible aux statistiques. Chaque utilisateur utilise un ensemble différent de données, d'arguments de recherche, de variables, etc. qu'il fournit en entrée au même proc mémorisé. ASE fait des choix d'index au moment de l'exécution, basé sur (a) les données d'entrée exactes (Arguments de recherche) par rapport à (b) l'utilité des indices. Et tout ce qu'il sait, c'est l'info statistique selon les derniers UPDATE STATS.