SQL Server NOLOCK i dołącza

Tło: Mam zapytanie krytyczne dla wydajności, które chciałbym uruchomić i nie obchodzą mnie brudne odczyty.

Moje pytanie brzmi; Jeśli używam złączeń, czy muszę również określać wskazówkę NOLOCK?

Na przykład; jest:

SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b WITH (NOLOCK) ON a.ID = b.ID

Równoważny:

SELECT * FROM table1 a WITH (NOLOCK)
INNER JOIN table2 b ON a.ID = b.ID

A może będę musiał określić (NOLOCK)wskazówkę dotyczącą łączenia, aby upewnić się, że nie blokuję połączonej tabeli?

Nie odniosę się do READ UNCOMMITTEDargumentu, tylko do twojego pierwotnego pytania.

Tak, potrzebujesz WITH(NOLOCK)na każdej tabeli łączenia. Nie, twoje zapytania nie są takie same.

Spróbuj tego ćwiczenia. Rozpocznij transakcję i wstaw wiersz do tabeli 1 i tabeli 2. Nie zatwierdzaj jeszcze ani nie wycofuj transakcji. W tym momencie pierwsze zapytanie zwróci się pomyślnie i będzie zawierać niezatwierdzone wiersze; Twoje drugie zapytanie nie zwróci, ponieważ tabela2 nie zawiera WITH(NOLOCK)podpowiedzi.

Byłem prawie pewien, że musisz określić NOLOCKdla każdego JOINw zapytaniu. Ale moje doświadczenie ograniczało się do SQL Server 2005.

Kiedy wyszukałem MSDN tylko w celu potwierdzenia, nie mogłem znaleźć nic konkretnego. Poniższe stwierdzenia wydają się skłaniać mnie do myślenia, że ​​w 2008 r. Dwa powyższe stwierdzenia są równoważne, chociaż w przypadku 2005 r. Tak nie jest:

[SQL Server 2008 R2]

Wszystkie wskazówki dotyczące blokad są propagowane do wszystkich tabel i widoków, do których ma dostęp plan kwerend , w tym do tabel i widoków, do których istnieją odniesienia w widoku. Ponadto SQL Server przeprowadza odpowiednie testy spójności blokad.

[SQL Server 2005]

W SQL Server 2005 wszystkie wskazówki dotyczące blokad są propagowane do wszystkich tabel i widoków, do których istnieją odniesienia w widoku. Ponadto SQL Server przeprowadza odpowiednie testy spójności blokad.

Dodatkowo należy zwrócić uwagę - i dotyczy to zarówno lat 2005, jak i 2008:

Wskazówki dotyczące tabeli są ignorowane, jeśli plan kwerend nie uzyskuje dostępu do tabeli. Może to być spowodowane tym, że optymalizator w ogóle nie chce uzyskiwać dostępu do tabeli lub zamiast tego uzyskuje się dostęp do widoku indeksowanego. W tym drugim przypadku dostęp do widoku indeksowanego można uniemożliwić za pomocą OPTION (EXPAND VIEWS)wskazówki dotyczącej zapytania.

Ani. Ustawiasz poziom izolacji, READ UNCOMMITTEDktóry jest zawsze lepszy niż podawanie indywidualnych wskazówek dotyczących blokady. Lub, jeszcze lepiej, jeśli zależy Ci na szczegółach, takich jak spójność , użyj izolacji migawki .