ADO.Net, requêtes paramétrées et mise en cache de plan

Question

Si une application de bureau utilise ADO.Net pour se connecter à SQL Server 2008 R2 et utilise une requête paramétrée ad hoc pour récupérer des données, que se passe-t-il lorsque deux instances différentes de l'application exécuter la requête? Est-ce que le premier appel est compilé et le second utilise la version en mémoire?

Exemple requête:

SqlConnection conn = new SqlConnection(_connectionString); 
conn.Open(); 
string s = "SELECT email, passwd, login_id, full_name " + 
    "FROM members WHERE email = @email"; 
SqlCommand cmd = new SqlCommand(s); 
cmd.Parameters.Add("@email", email); 
SqlDataReader reader = cmd.ExecuteReader(); 

Je remarque les performances des requêtes lentes la première fois que la requête est tiré et appels consécutifs semblent être très bien. Je me demande simplement si ce comportement est global pour chaque instance de l'application ou si la première fois que la requête est déclenchée à partir d'une instance, elle améliore les performances pour toutes les instances de l'application qui utilisent cette requête.

Answer 1

SQL Server devra analyser la requête la première fois qu'il l'obtient et trouver un plan d'exécution raisonnablement performant pour celui-ci.

Une fois qu'il a fait cela, la requête

SELECT email, passwd, login_id, full_name FROM members WHERE email = @email 

et son plan d'exécution sont stockés dans le cache de plan.

Tant que le cache de plan a assez de place, toute exécution ultérieure de cette exactement la même requête (« même » jusqu'à la dernière virgule, espace ou quoi que ce soit! Il doit être absolument le même SQL) sera réutilisez ce plan d'exécution à partir du cache de plan. Donc oui - la toute première fois qu'une requête est exécutée (par exemple après un redémarrage de SQL Server), un léger retard sera perceptible, mais une fois exécuté et le plan de requête mis en cache, il devrait fonctionner beaucoup mieux - par exemple toutes les connexions au SQL Server qui utilisera exactement la même requête. L'exigence de la même requête illustre également pourquoi il est si mauvais - également du point de vue des performances - d'enchaîner vous-même votre SQL et de mettre les valeurs de la requête dans le texte de la requête - de cette façon, chaque requête avec values ​​est un nouveau texte de requête SQL et toute l'histoire doit être répétée pour chaque requête. Si vous utilisez requêtes paramétrées comme vous êtes, la requête reste la même et donc un plan d'exécution en cache peut être réutilisé - seules les valeurs des paramètres changent, mais cela n'affecte pas le plan d'exécution de la requête et la possibilité de réutilisation un plan en cache

Answer 2

Je pense que la compilation et le plan de cache n'ont pas d'importance ici (la requête SQL est triviale). La chose la plus importante est le cache disque. Il semble que la première fois que vous avez des lectures physiques à partir du disque, vous avez des lectures logiques (à partir du cache). Ce cache disque est au niveau du serveur.

Vous pouvez ajouter commande

DBCC DROPCLEANBUFFERS 

befor vous demandez, pour forcer nettoyer le cache disque. Donc, vous pouvez vérifier les performances

Answer 3

Oui, les plans d'exécution de requête paramétrés sont encaissés et réutilisés pour chaque connexion jusqu'à ce qu'ils soient poussés par la casse. Vous pouvez vérifier si le plan a été recompilé dans Profiler avec l'événement SP:Recompile. Plus à ce sujet, vous pouvez lire dans MSDN Article Execution Plan Caching and Reuse

Mais, dans votre cas, je pense, plus important rôle joue l'encaissement des données.Tant que vous exécutez la requête, les premières pages de données sont chargées dans la RAM et restent là jusqu'à ce qu'elles soient poussées de la casse. Il peut affecter l'heure d'exécution des requêtes suivantes si elles transmettent la même valeur au paramètre @email ou si vous n'avez pas d'index sur le champ email (ou les deux).