Обърнете внимание, че можете да посочите nolock за всяка таблица.
Обикновено използвах nolock в сложни SELECT заявки, но само за малките справочни таблици, които почти никога не се променят, и за данни само за показване. Знаете таблиците, в които са изброени цените за текущата половин година или търсенето на идентификатори към низове и т.н. Неща, които се променят само с големи актуализации, след които сървърите обикновено се рестартират рутинно.
Това значително подобри производителността, намали шанса за блокиране в най-натоварените моменти и по-важното беше наистина забележимо по време на най-лошите моменти за заявки, които докоснаха много таблици (което е логично, те трябва да получат по-малко заключвания и тези странични таблици често се използват почти навсякъде, като често намаляват от 7-8 до 4 таблици, които трябва да бъдат заключени)
Но бъдете много внимателни при добавянето му, не бързайте и не го правете рутинно. Няма да навреди, когато се използва правилно, но ще навреди ужасно, когато се използва неправилно.
Не го използвайте за много критични неща, неща, които изчисляват и т.н., защото ще стане непоследователно, всичко, което води до запис рано или късно.
Друга такава оптимизация е ROWLOCK, която заключва само на ниво ред. Това е основно полезно при актуализиране (или изтриване) на таблици, където редовете не са свързани един с друг, като таблици, в които поставяте само записи в журнал (и редът, в който са вмъкнати, няма значение). Ако имате схема, при която някъде в края на транзакция се записва регистрационен запис в някаква таблица, това също може да ускори значително.
Ако вашата база данни има сравнително нисък процент записи, може да не си струва. Имах съотношение четене:запис под 2:1.
Някои URL адреси, които запазих, докато работех по това:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/
