IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

DB2 Discussion :

Performance et utilisation des indexes


Sujet :

DB2

  1. #1
    Membre confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2002
    Messages
    137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2002
    Messages : 137
    Points : 621
    Points
    621
    Par défaut Performance et utilisation des indexes
    Bonjour,

    Je rencontre des problèmes de performance pour accéder aux données d'une table et je ne parviens pas a comprendre ce qu'il se passe, ni comment résoudre le problème.

    La situation :
    J'ai une table de 270 millions d'enregistrements contenant diverses informations dont les champs
    • Id : primary key
    • IdRegroupeOption : un Id de regroupement (0 sur toutes les lignes sauf une)


    Les deux champs ci-dessus disposent d'un index, non-unique dans le cas du 2eme champ
    La table a été réorganisée, les indexes aussi et le runstats a été fait


    Le problème :
    Les requêtes suivantes s'exécutent en quelques millisecondes :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption=347696871
    1 ligne

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT * FROMMAGROSSETABLE a WHERE a.Id=347696871
    1 ligne (la même dans ce cas particulier)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption=347696871
    UNION ALL
    SELECT * FROM MAGROSSETABLE a WHERE a.Id= 347696871
    2 fois la même ligne







    Par contre les requêtes suivantes mettent une éternité à s'exécuter (j'ai killé après 5 minutes de temps perdu) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption=347696871 OR a.Id=347696871
    devrait renvoyer 1 ligne ... mais je l'attends toujours

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption=347696871
    UNION
    SELECT * FROM MAGROSSETABLE a WHERE a.Id=347696871
    devrait renvoyer 1 ligne ... mais je l'attends toujours

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    SELECT DISTINCT * FROM (
    SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption = 347696871
    UNION ALL 
    SELECT * FROM MAGROSSETABLE  a WHERE a.Id = 347696871
    ) AS req
    devrait renvoyer 1 ligne ... mais je l'attends toujours


    Je ne comprends pas pourquoi DB2 part en TABLESCAN dès que je combine mes 2 critères au lieu d'utiliser les indexes, que ce soit via un UNION ou un OR ?!

    Est-ce que l'un d'entre vous aurait des pistes ?

    Merci d'avance pour votre aide.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 796
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 796
    Points : 52 823
    Points
    52 823
    Billets dans le blog
    5
    Par défaut
    Lisez les articles que j'ai écrit à ce sujet :
    https://sqlpro.developpez.com/cours/quoi-indexer/
    https://sqlpro.developpez.com/optimisation/indexation/
    Comme vous ne donnez pas le DDL complet de vos tables et que vous faites des SELECT * il y a peu de chance que les index soient utilisés... Vous le comprendrez en lisant les articles que j'ai écrit !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    953
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 953
    Points : 2 066
    Points
    2 066
    Par défaut
    Bonjour

    A priori, tout viens de la colonne indexée IdRegroupeOption (270M de lignes, 2 valeurs possibles).

    pour en être sur, utilise EXPLAIN pour comprendre les requetes et chemin d'accès que DB2 utilise (DB2 réécrit ls requêtes)
    bosse aussi sur les options possibles du RUNSTATS (COLGRP par ex)

    essaye d'utiliser les CTE, dans ton cas, ca sera plus efficace que des SELECT .. UNION..
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    WITH  REDUC1 As (SELECT * FROM MAGROSSETABLE a WHERE a.IdRegroupeOption=347696871);
    WITH  REDUC2 AS ...;
     
    SELECT * FROM REDUC1 
    union
    ...;
    excuse les erreurs possibles
    Ca fait 3 ans que je n'ai pas fait de DB2.
    ++

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 164
    Points : 38 976
    Points
    38 976
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Indexer une colonne (et non pas un champ !) qui ne peut prendre que deux valeurs n'a le plus souvent aucun intérêt, sauf cas particulier d'index couvrant...
    ...mais comme vous utilisez SELECT *, les index couvrants ne sont pas éligibles

    Voir ICI pourquoi il ne faut pas utiliser select *

    Dans votre cas, l'optimiseur tente probablement de trouver une stratégie permettant de satisfaire les deux requêtes, mais comme il n'y en a pas (index non éligible, car d'une part non discriminant, d'autre part, usage de SELECT *), alors il fait un table scan !

Discussions similaires

  1. [SQL2000] Utilisation des index ...
    Par scornille dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 03/05/2006, 16h07
  2. Utilisation des Indexes
    Par Wurlitzer dans le forum Oracle
    Réponses: 1
    Dernier message: 24/04/2006, 18h46
  3. Requête SELECT : limite d'utilisation des index
    Par DadaWeb dans le forum Requêtes
    Réponses: 7
    Dernier message: 07/12/2005, 22h24
  4. Compteur sur l'utilisation des index
    Par hkhan dans le forum Administration
    Réponses: 11
    Dernier message: 14/10/2004, 17h57
  5. Utilisation des "indexs" ?
    Par vandeyy dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 07/09/2004, 07h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo