web-dev-qa-db-fra.com

Performances de l'instruction VIEW par rapport à l'instruction SQL

J'ai une requête qui va quelque chose comme ce qui suit:

select <field list> 
from <table list>
where <join conditions>
and <condition list>
and PrimaryKey in (select PrimaryKey from <table list>
    where <join list> 
    and <condition list>)
and PrimaryKey not in (select PrimaryKey from <table list>
    where <join list>
    and <condition list>)

Les requêtes de sous-sélection ont toutes deux plusieurs requêtes de sous-sélection que je ne montre pas afin de ne pas encombrer la déclaration.

L'un des développeurs de mon équipe pense qu'une vue serait meilleure. Je ne suis pas d'accord en ce que l'instruction SQL utilise des variables transmises par le programme (en fonction de l'identifiant de connexion de l'utilisateur).

Existe-t-il des règles strictes sur le moment d'utilisation d'une vue par rapport à l'utilisation d'une instruction SQL? Quels types de problèmes de gain de performances existe-t-il dans l'exécution d'instructions SQL par rapport à des tables classiques par rapport à des vues? (Notez que toutes les conditions de jointure/où sont appliquées aux colonnes indexées, cela ne devrait donc pas être un problème.)

EDIT pour clarification ...

Voici la requête avec laquelle je travaille:

select obj_id
from object
where obj_id in( 
(select distinct(sec_id) 
        from security 
        where sec_type_id = 494
        and (
            (sec_usergroup_id = 3278 
            and sec_usergroup_type_id = 230)
            or
            (sec_usergroup_id in (select ug_gi_id 
            from user_group 
            where ug_ui_id = 3278)
            and sec_usergroup_type_id = 231)
        )
        and sec_obj_id in (
        select obj_id from object 
        where obj_ot_id in (select of_ot_id 
            from obj_form 
            left outer join obj_type 
            on ot_id = of_ot_id 
            where ot_app_id = 87
            and of_id in (select sec_obj_id 
                from security
                where sec_type_id = 493
                and (
                    (sec_usergroup_id = 3278 
                    and sec_usergroup_type_id = 230)
                    or
                    (sec_usergroup_id in (select ug_gi_id 
                        from user_group 
                        where ug_ui_id = 3278)
                    and sec_usergroup_type_id = 231)
                    )                
            )   
            and of_usage_type_id  = 131
        )
        )   
        )
)
or 
(obj_ot_id in (select of_ot_id 
        from obj_form
        left outer join obj_type 
        on ot_id = of_ot_id 
        where ot_app_id = 87
        and of_id in (select sec_obj_id 
            from security
            where sec_type_id = 493
            and (
                (sec_usergroup_id = 3278 
                and sec_usergroup_type_id = 230)
                or
                (sec_usergroup_id in (select ug_gi_id 
                    from user_group 
                    where ug_ui_id = 3278)
                and sec_usergroup_type_id = 231)
                )
        )
        and of_usage_type_id  = 131

    )
    and
    obj_id not in (select sec_obj_id 
        from security 
        where sec_type_id = 494)
)
databaseperformanceviewsql
16
Matt W.

En fonction du fournisseur de la base de données, l’exécution d’une requête sur une vue combine généralement le code SQL défini dans la vue, les prédicats de clause Where et les expressions de tri de la clause Order By, ajoutés au SQL que vous transmettez à la vue. une requête SQL complète combinée à exécuter. Ceci est ensuite exécuté comme s'il avait lui-même été transmis au processus de requête, il n'y aurait donc aucune différence.

Les vues sont un outil d’organisation, pas un outil d’amélioration des performances.

De Résolution de vue SQL Server

Lorsqu'une instruction SQL fait référence à une vue non indexée, l'analyseur et l'optimiseur de requêtes analysent la source de l'instruction SQL et de la vue, puis les résolvent en un seul plan d'exécution. Il n'y a pas un plan pour l'instruction SQL et un plan séparé pour la vue.

50
Charles Bretana

Les vues régulières (non indexées/matérialisées) ne sont que des alias. ils n'offrent aucun avantage de performance. La sélection dans une vue génère exactement le même plan de requête que la sélection directe dans la table.

8
RickNZ

Vues de côté, les clauses PrimaryKey AND ne sont-elles pas redondantes? Si la valeur PrimaryKey est IN une liste, ne serait-ce pas IN l'autre liste? Je pense que condenser ces deux clauses en un seul améliorerait les performances.

0
simeonwillbanks