Vous pouvez utiliser l'une de ces deux requêtes pour voir le total des lectures logiques et le total des lectures physiques.
SELECT DB_NAME(st.dbid) Db,
OBJECT_NAME(st.objectid, st.dbid) Prc,
qs.execution_count,
qs.total_logical_reads,
qs.total_physical_reads,
qs.statement_start_offset,
qs.statement_end_offset,
st.text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st;
SELECT DB_NAME(database_id) Db,
OBJECT_NAME(object_id, database_id) Prc,
execution_count,
total_logical_reads,
total_physical_reads
FROM sys.dm_exec_procedure_stats ps;
Le premier décompose cela par instruction, le second compte dans toute la procédure.
Les lectures physiques sont des lectures sur le disque, les lectures logiques sont sur la mémoire. Vous pouvez l'utiliser pour déterminer quelles procédures ou instructions sont les plus coûteuses de votre système et essayer de les régler.
Gardez à l'esprit que, bien que les lectures logiques soient nettement moins chères que les lectures physiques, elles sont toujours coûteuses, donc en réduire le nombre (par exemple en ajoutant un index approprié) peut accélérer l'exécution de vos requêtes.
Il y a beaucoup de colonnes supplémentaires dans les DMV ci-dessus qui pourraient également vous intéresser.
Comment un index aide-t-il à réduire les lectures logiques?
Dans SQL Server, toutes les données sont organisées en blocs, d'une taille de 8 Ko. Ces blocs sont appelés "pages".
Chaque table contient des pages "meta" qui contiennent des informations sur le struktur de la table ainsi que des pages pata. Si aucun index n'existe et que vous exécutez une requête comme SELECT * FROM tbl WHERE Id = 7SQL Server, vous devez rechercher ceci ou ces lignes dans la table entière. Il lit donc une page à la fois, parcourt toutes les lignes de chaque page pour déterminer les lignes qui correspondent à la WHEREclause. Donc, si la table nécessite 1 000 000 de pages à stocker, cette requête nécessitera 1 000 000 de lectures logiques.
Si vous avez un index, SQL Server trie les données de manière logique dans les pages et établit une liste liée entre les pages. Cela permet d'exécuter des requêtes avec un ORDER BYà exécuter sans opération de tri coûteuse. Mais plus important encore que le tri, SQL Server ajoute un arbre B + à la table. Un arbre B + est une structure comparable à l'index d'un livre, où la recherche d'un mot clé spécifique me permet de passer directement à la page qui contient le mot clé. Le livre typique n'a qu'un seul niveau d'index alors qu'un arbre B + peut en avoir plusieurs. Pensez simplement à un grand livre, où l'index lui-même fait plusieurs pages. Dans un cas comme celui-ci, il est logique d'ajouter une couche d'index supplémentaire qui nous indique sur quelle page les mots d'index commençant par Sdoivent être trouvés.
Les arbres B + sont optimisés pour avoir le moins de niveaux possible tout en offrant la propriété que tout enregistrement dans l'index peut être trouvé en lisant une page par niveau d'index. Supposez donc la WHERE Id = 7requête ci-dessus lorsque vous avez un index trié par Id. Disons que l'indice a 5 niveaux. Maintenant, pour trouver tous les enregistrements qui correspondent à cette requête, je dois lire une page par niveau d'index (c'est-à-dire 5 pages). Cela s'appelle une "recherche d'index". S'il y a plusieurs enregistrements qui correspondent à la facture, je devrai peut-être suivre l'index trié pendant un certain temps pour les récupérer tous. Mais supposons qu'il n'y ait qu'un seul enregistrement.
Ainsi, sans l'index en cours d'exécution, cette requête a nécessité 1 000 000 de lectures, avec indes, elle a nécessité 5 lectures. Même si une lecture logique est une opération en mémoire, il y a toujours un coût substantiel - en fait, c'est l'opération la plus coûteuse dans une requête triviale comme celle ci-dessus. Ainsi, la réduction du nombre de lectures logiques nécessaires d'un facteur 200 000 accélérera votre requête d'un facteur similaire.
Ainsi, une lecture logique n'est pas équivalente à une analyse de table, mais une analyse de table provoque beaucoup plus de lectures logiques qu'une recherche d'index.
Vous pouvez utiliser SQL Profiler. Lorsque vous démarrez la trace, vous devez choisir RPC Completed, SP Starting, SP StmtStarting et SP StmtCompleted (voir l'image ci-dessous)
Cela vous permettra de voir chaque requête qui s'exécute à l'intérieur des procédures stockées. Il vous permettra de voir combien de fois une procédure stockée imbriquée est appelée. Une fois la trace terminée, vous devez l'enregistrer. Ensuite, rouvrez-le, et après cela, vous pourrez filtrer (avec le bouton "Filtres de colonne") pour trouver les requêtes qui vous posent problème. (ex: les requêtes qui ont pris plus de x lectures ou qui ont duré plus de x secondes (durée) ...)
Les options du profileur que je vous ai montrées montrent également le plan d'exécution, ce qui est également très utile.
la source
Cela semble être une question générale d'optimisation des requêtes. D'après votre description, je voudrais:
la source