Différentes façons de définir quelle base de données utiliser?

Question

J'essaie de trouver les différences dans la façon dont vous pouvez définir quelle base de données utiliser dans SSMS.

est-il une différence fonctionnelle entre l'utilisation de la chute 'Bases de données disponibles de la liste déroulante

Adventure works Available Databases dropdown,

la base de données étant définie dans la requête

SELECT * FROM AdventureWorks2008.dbo.Customers 

et indiquant la base de données à la début?

USE AdventureWorks2008 
GO 
SELECT * FROM dbo.Customers 

Je suis intéressé de savoir s'il y a une différence en termes de performance ou quelque chose qui se passe dans les coulisses pour chaque cas.

Nous vous remercions de votre aide

Answer 1

Oui, il y a. Une très petite surcharge est ajoutée lorsque vous utilisez "USE AdventureWorks2008" car elle l'exécutera sur la base de données chaque fois que vous exécuterez la requête. Il imprimera également la "commande (s) terminée avec succès.". Cependant, il est si petit frais généraux et si vous êtes d'accord avec ce message, alors ne vous souciez pas de cela.

Answer 2

Oui, il peut y avoir une différence.

Lorsque vous exécutez des instructions de ce type: SELECT * FROM AdventureWorks2008.dbo.Customers dans le contexte de autre base de données (et non AdventureWorks2008) que les paramètres d'une autre base de données sont appliqués. Tout d'abord, toute base de données a son Compatibility Level qui peut être différent, donc il peut limiter l'utilisation de certains codes, par exemple vous ne pouvez pas utiliser APPLY opérateur dans le contexte de base de données avec CL mis à 80 mais vous pouvez le faire dans La base de données avec CL> = 90

Deuxièmement, chaque base de données possède son propre ensemble d'options telles que AUTO_UPDATE_STATISTICS_ASYNC et Forced Parameterization qui peuvent affecter votre plan de requête. J'ai rencontré quelques cas où le contexte de base de données a influencé le plan:

Un cas était quand j'ai créé l'index filtré pour une table et il a été utilisé dans le plan jusqu'à ce que j'ai exécuté ma requête dans le contexte de la base de données avec le paramétrage simple , et il n'a pas été utilisé pour la même requête lorsqu'il est exécuté dans le contexte de la base de données avec le paramétrage forcé. Lorsque j'ai utilisé l'indice pour forcer cet index j'ai l'erreur que le plan de requête ne peut pas être produit en raison de l'indice de requête, donc j'ai besoin d'enquêter et j'ai découvert que ma requête était paramétrée et fld = 0 et il ne pouvait pas utiliser mon index filtré avec la condition fld = 0.

Le deuxième cas a été la table reguarding estimation de cardinalité: nous utilisons des tables mise en scène pour charger les données dans nos procédures ETL, puis passer ensuite aux tables réelles comme ceci:

insert into stg with(tablock); 
... 
truncate table actual; 
alter table stg swith to actual; 

Toutes les tables de mise en scène sont vides lorsque le procédure compile mais dans le proc, ils sont remplis avec les données, donc quand nous faisons des jointures entre eux, ils ne sont plus emty. Passer de 0 lignes à des lignes non-0 déclenche une recompilation d'instructions qui devrait prendre en compte le nombre réel de lignes, mais cela ne s'est pas produit sur le serveur de production, donc toutes les estimations étaient fausses (1 ligne pour chaque table) .La cause était AUTO_UPDATE_STATISTICS_ASYNC définie sur ON dans la base de données de production. Maintenant, imaginez que vous ayez 2 db: db1 et db2 avec cette option respectivement ON et OFF, dans db1 ce code aura des estimations erronées alors que si vous l'exécutez en db2 en utilisant db1.dbo.stg il aura de bonnes estimations. Le temps d'exécution sera très différent dans ces 2 bases de données.