Pamiętaj, że możesz określić nolock na podstawie tabeli.
Zwykle używałem nolock w złożonych zapytaniach SELECT, ale tylko dla małych tabelek przeglądowych, które prawie nigdy się nie zmieniały, oraz dla danych tylko do wyświetlania. Znasz tabele, które zawierają ceny na bieżące półrocze, wyszukiwanie identyfikatorów w ciągach itp. Rzeczy, które zmieniają się tylko po dużych aktualizacjach, po których serwery i tak są zwykle rutynowo restartowane.
To znacznie poprawiło wydajność, zmniejszyło szansę na zakleszczenie w najbardziej ruchliwych czasach, a co ważniejsze było to naprawdę zauważalne w najgorszych momentach dla zapytań, które dotykały wielu tabel (co jest logiczne, muszą uzyskać mniej blokad, a te tabele boczne są często używane prawie wszędzie, często zmniejszając się z 7-8 do 4 stołów, które trzeba zablokować)
Ale bądź bardzo ostrożny dodając to, nie spiesz się i nie rób tego rutynowo. Nie będzie bolało, gdy będzie używane prawidłowo, ale będzie strasznie boleć, gdy zostanie użyte niewłaściwie.
Nie używaj go do bardzo krytycznych rzeczy, rzeczy, które obliczają itp., ponieważ stanie się niespójne, cokolwiek, co prędzej czy później doprowadzi do pisania.
Inną taką optymalizacją jest ROWLOCK, który blokuje tylko na poziomie wiersza. Jest to przydatne głównie podczas aktualizowania (lub usuwania) tabel, w których wiersze nie są ze sobą powiązane, na przykład tabel, w których umieszcza się tylko rekordy dziennika (a kolejność ich wstawiania nie ma znaczenia). Jeśli masz schemat, w którym gdzieś pod koniec transakcji zapisywany jest rekord dziennika w jakiejś tabeli, może to również znacznie przyspieszyć.
Jeśli twoja baza danych ma stosunkowo niski procent zapisów, może to nie być tego warte. Miałem stosunek odczytu do zapisu poniżej 2:1.
Niektóre adresy URL, które zapisałem podczas pracy nad tym:
http://www.developerfusion.com/article/1688/ blokady serwera sql/4/
