Všimněte si, že můžete zadat nolock na základě tabulky.
Typicky jsem nolock používal ve složitých SELECT dotazech, ale pouze pro malé vyhledávací tabulky, které se téměř nikdy neměnily, a pro data pouze pro zobrazení. Znáte tabulky, které uvádějí ceny za aktuální půlrok, nebo vyhledávání id do řetězců atd. Věci, které se mění pouze s velkými aktualizacemi, po kterých se servery stejně obvykle rutinně restartují.
To výrazně zlepšilo výkon, snížilo možnost uváznutí v nejrušnějších časech, a co je důležitější, bylo to opravdu patrné během okamžiků nejhorších případů u dotazů, které se dotýkaly mnoha tabulek (což je logické, musí získat méně zámků a ty postranní tabulky se často používají téměř všude, často se zmenšují ze 7–8 na 4 stoly, které je třeba uzamknout)
Při přidávání však buďte velmi opatrní, nespěchejte a nedělejte to běžně. Při správném použití to nebude bolet, ale při nesprávném použití to bude bolet příšerně.
Nepoužívejte to pro vysoce kritické věci, věci, které počítají atd., protože to bude nekonzistentní, cokoli, co dříve nebo později povede k zápisu.
Další takovou optimalizací je ROWLOCK, který se uzamkne pouze na úrovni řádku. To je užitečné hlavně při aktualizaci (nebo mazání) tabulek, kde řádky spolu nesouvisí, jako jsou tabulky, do kterých vkládáte pouze záznamy protokolu (a na pořadí, v jakém jsou vkládány, nezáleží). Pokud máte schéma, že někde na konci transakce je záznam protokolu zapsán do nějaké tabulky, může se to také značně urychlit.
Pokud má vaše databáze relativně nízké procento zápisů, nemusí to stát za to. Měl jsem poměr čtení:zápis pod 2:1.
Některé adresy URL, které jsem si uložil, když jsem na tom pracoval:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/