SQL Server NOLOCK et jointures
Arrière-plan: j'ai une requête critique en termes de performances que je voudrais exécuter et je me moque des lectures sales.
Ma question est; Si j'utilise des jointures, dois-je également spécifier l'indicateur NOLOCK?
Par exemple; est:
SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b WITH (NOLOCK) ON a.ID = b.ID
Équivalent à:
SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b ON a.ID = b.ID
Ou devrais-je spécifier l'indicateur (NOLOCK) sur la jointure pour m'assurer que je ne verrouille pas la table jointe?
Je ne parlerai pas de l'argument READ UNCOMMITTED, mais de votre question initiale.
Oui, vous avez besoin de WITH(NOLOCK) sur chaque table de la jointure. Non, vos questions ne sont pas les mêmes.
Essayez cet exercice. Commencez une transaction et insérez une ligne dans table1 et table2. Ne pas valider ou annuler la transaction pour le moment. À ce stade, votre première requête renverra avec succès et inclura les lignes non validées. Votre seconde requête ne renverra pas car table2 n'a pas l'indice WITH(NOLOCK).
J'étais à peu près sûr que vous deviez spécifier la NOLOCK pour chaque JOIN de la requête. Mais mon expérience était limitée à SQL Server 2005.
Lorsque j'ai regardé MSDN juste pour confirmer, je n'ai rien trouvé de précis. Les déclarations ci-dessous semblent me faire penser que pour 2008, vos deux déclarations ci-dessus sont équivalentes bien que pour 2005, ce n'est pas le cas:
[SQL Server 2008 R2]
Tous les indicateurs de verrouillage sont propagés à toutes les tables et vues qui sont accessibles par le plan de requête, y compris les tables et les vues référencées dans une vue. SQL Server effectue également les contrôles de cohérence des verrous correspondants.
[SQL Server 2005]
Dans SQL Server 2005, tous les indicateurs de verrouillage sont propagés à toutes les tables et vues référencées dans une vue. SQL Server effectue également les contrôles de cohérence des verrous correspondants.
En outre, il faut noter - et cela s'applique à la fois à 2005 et à 2008:
Les indicateurs de table sont ignorés si le plan de requête n'accède pas à la table. Cela peut être causé par le choix de l’optimiseur de ne pas accéder à la table ou par l’accès à une vue indexée. Dans ce dernier cas, il est possible d'empêcher l'accès à une vue indexée en utilisant l'indicateur de requête
OPTION (EXPAND VIEWS).
Ni. Vous définissez le niveau d'isolation sur READ UNCOMMITTED , ce qui est toujours préférable à l'indication d'indices de verrouillage individuels. Ou, mieux encore, si vous tenez à des détails tels que cohérence , utilisez isolation de capture instantanée .