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

MS SQL Server Discussion :

[avis] Optimisation de requette


Sujet :

MS SQL Server

  1. #1
    Membre habitué Avatar de mioux
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2005
    Messages
    367
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

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

    Informations forums :
    Inscription : Novembre 2005
    Messages : 367
    Points : 191
    Points
    191
    Par défaut [avis] Optimisation de requette
    Salut à tous

    J'ai un cube de données de 90 000 000 de lignes, dans laquelle je veux sélectionner 18 lignes distinctes.

    Ma question :
    Vaut il mieux faire 1 requette qui va me renvoyer mes 18 lignes sachant que chaque ligne est filtrée par un OR (donc 17 OR dans la requette) ou est ce que faire 18 sélection différentes seront plus rapide ?

    Tout ceci sachant que le serveur hôte devrait être un bi-processeur (cadencés à je sais pas quelle fréquence) chacun d'eux étant dual-core, et qu'il y aura 8Go de RAM (sans plus de précisions quand à la fréquence de celle ci, ni le type )
    Avantage, il sera un serveur de base de données seules (donc pas de IIS à gérer en plus )

    Je ne peux pas vous aider plus, car pour le moment, on a pas le serveur, et on a pas de données dans le cube...

    EDIT : Précision du chef à l'instant :
    Machine
    PowerEdgeTM 2950

    Processeurs
    Double cœur Intel Xéon 5110, 4 Mo cache, 1.6 Ghz

    Mémoire
    8 Go

  2. #2
    Rédacteur/Modérateur

    Avatar de Fabien Celaia
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2002
    Messages
    4 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Service public

    Informations forums :
    Inscription : Octobre 2002
    Messages : 4 224
    Points : 19 566
    Points
    19 566
    Billets dans le blog
    25
    Par défaut
    Toujours envisager la version ensembliste !

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 907
    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 907
    Points : 51 656
    Points
    51 656
    Billets dans le blog
    6
    Par défaut
    Dans ce cas essayez un UNION :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    SELECT ...
    FROM   ...
    WHERE ... 1 ...
    UNION
    SELECT ...
    FROM   ...
    WHERE ... 2 ...
    ...
    UNION
    SELECT ...
    FROM   ...
    WHERE ... 18 ...
    A +

  4. #4
    Rédacteur/Modérateur

    Avatar de Fabien Celaia
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2002
    Messages
    4 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Service public

    Informations forums :
    Inscription : Octobre 2002
    Messages : 4 224
    Points : 19 566
    Points
    19 566
    Billets dans le blog
    25
    Par défaut
    Je crois pas que l'UNION soit une soluce dans ce cas : ça risque de générer un multiple de tablescan (ou d'accès via index). Au pire, le OR fera la même chose... et reste plus lisible.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 907
    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 907
    Points : 51 656
    Points
    51 656
    Billets dans le blog
    6
    Par défaut
    Tout dépend effectivement de l'indexation sous jacente....

    A +

  6. #6
    Membre habitué Avatar de mioux
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2005
    Messages
    367
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

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

    Informations forums :
    Inscription : Novembre 2005
    Messages : 367
    Points : 191
    Points
    191
    Par défaut
    le truc c'est que je sais pas si
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    SELECT a, b, c
    FROM table
    WHERE a IS NOT NULL AND ENTITE_ID = 'id courant' AND (TYPE_ID = 'type recherché 1' OR 'type_recherché_2' OR ...)
    sera plus rapide que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    SELECT a, b, c
    FROM table
    WHERE a IS NOT NULL AND ENTITE_ID = 'id courant' AND TYPE_ID = 'type recherché 1'
    UNION
    SELECT a, b, c
    FROM table
    WHERE a IS NOT NULL AND ENTITE_ID = 'id courant' AND TYPE_ID = 'type recherché 2'
    UNION ...
    On a fais des tests sur une table avec ~ 1 000 000 de lignes (ce qui représente ~ 1% du nombre total de ligne qu'il y aura dans la base de données définitive) on a une différence de 2 secondes lors de l'exécution de ces deux requettes (celle avec les OU étant plus rapide)

    Seulement, en quadruplant le nombre de lignes, il y a toujours 2 secondes de différences... l'écart ne se creuse pas...

    C'est pour ca qu'on voulais l'avis d'experts

Discussions similaires

  1. Réponses: 13
    Dernier message: 18/07/2011, 17h24
  2. [Avis] Optimiser mon code
    Par apokal dans le forum Débuter
    Réponses: 5
    Dernier message: 08/11/2008, 20h05
  3. [MSSQL 2k5] Optimisation de requettes SQL
    Par mioux dans le forum MS SQL Server
    Réponses: 0
    Dernier message: 06/09/2007, 15h19
  4. tentative d'optimisation de requettes
    Par KINENVEU dans le forum Requêtes
    Réponses: 15
    Dernier message: 12/08/2007, 23h27
  5. Optimisation de requette TABLE ACCESS (FULL)
    Par e77em dans le forum Oracle
    Réponses: 10
    Dernier message: 16/09/2005, 11h39

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