探討：在每個表后面都加onlock是否合適
為了更好的討論是否合適，我們先解釋一些基本問題。
什么是并發訪問：同一時間有多個用戶訪問同一資源,并發用戶中如果有用戶對資源做了修改，此時就會對其它用戶產生某些不利的影響，例如：
1.臟讀
一個用戶對一個資源做了修改，此時另外一個用戶正好讀取了這條被修改的記錄，然后，第一個用戶放棄修改，數據回到修改之前，這兩個不同的結果就是臟讀。
2.不可重復讀
一個用戶的一個操作是一個事務，這個事務分兩次讀取同一條記錄，如果第一次讀取后，有另外用戶修改了這個數據，然后第二次讀取的數據正好是其它用戶修改的數據，這樣造成兩次讀取的記錄不同，如果事務中鎖定這條記錄就可以避免。
3.幻讀
指用戶讀取一批記錄的情況，用戶兩次查詢同一條件的一批記錄，第一次查詢后，有其它用戶對這批數據做了修改，方法可能是修改，刪除，新增，第二次查詢時，會發現第一次查詢的記錄條目有的不在第二次查詢結果中，或者是第二次查詢的條目不在第一次查詢的內容中。
為什么會在查詢的表后面加nolock標識？為了避免并發訪問產生的不利影響，SQLServer有兩種并發訪問的控制機制：鎖、行版本控制,表后面加nolock是解決并發訪問的方案之一。
1>鎖,每個事務對所依賴的資源會請求不同類型的鎖，它可以阻止其他事務以某種可能會導致事務請求鎖出錯的方式修改資源。當事務不再依賴鎖定的資源時，鎖將被釋放。
鎖的類型：1:表類型：鎖定整個表；2:行類型：鎖定某個行；3:文件類型：鎖定某個數據庫文件；4:數據庫類型：鎖定整個數據庫；5:頁類型：鎖定8K為單位的數據庫頁。
鎖的分類還有一種分法，就是按用戶和數據庫對象來分：
1)從數據庫系統的角度來看：分為獨占鎖（即排它鎖），共享鎖和更新鎖
1.共享(S)：用于不更改或不更新數據的操作（只讀操作），一般常見的例如select語句。
2.更新(U)：用于可更新的資源中。防止當多個會話在讀取、鎖定以及隨后可能進行的資源更新時發生常見形式的死鎖。
3.排它(X)：用于數據修改操作，例如INSERT、UPDATE或DELETE。確保不會同時同一資源進行多重更新。
2)從程序員的角度看：分為樂觀鎖和悲觀鎖
1.樂觀鎖：完全依靠數據庫來管理鎖的工作。
2.悲觀鎖：程序員自己管理數據或對象上的鎖處理。
一般程序員一看到什么鎖之類，覺的特別復雜，對專業的DBA當然是入門級知識了。可喜的是程序員不用去設置,控制這些鎖，SQLServer通過設置事務的隔離級別自動管理鎖的設置和控制。鎖管理器通過查詢分析器分析待執行的sql語句，來判斷語句將會訪問哪些資源，進行什么操作，然后結合設定的隔離級別自動分配管理需要用到的鎖。
2>:行版本控制:當啟用了基于行版本控制的隔離級別時，數據庫引擎將維護修改的每一行的版本。應用程序可以指定事務使用行版本查看事務或查詢開始時存在的數據，而不是使用鎖保護所有讀取。通過使用行版本控制，讀取操作阻止其他事務的可能性將大大降低。也就是相當于針對所有的表在查詢時都會加上nolock，同樣會產生臟讀的現象，但差別在于在一個統一管理的地方。說到了基于行版本控制的隔離級別，這里有必要說下隔離級別的概念。
隔離級別的用處：控制鎖的應用，即什么場景應用什么樣的鎖機制。
最終目的：解決并發處理帶來的種種問題。
隔離級別的分類：
1.未提交讀,隔離事務的最低級別，只能保證不讀取物理上損壞的數據;
2.已提交讀,數據庫引擎的默認級；
3.可重復讀；
4.可序列化；隔離事務的最高級別，事務之間完全隔離。
小結
NOLOCK語句執行時不發出共享鎖，允許臟讀，等于READUNCOMMITTED事務隔離級別。nolock確實在查詢時能提高速度，但它并不是沒有缺點的，起碼它會引起臟讀。
nolock的使用場景(個人觀點)：
1.數據量特別大的表，犧牲數據安全性來提升性能是可以考慮的；
2.允許出現臟讀現象的業務邏輯，反之一些數據完整性要求比較嚴格的場景就不合適了，像金融方面等。
3.數據不經常修改的表，這樣會省于鎖定表的時間來大大加快查詢速度。
綜上所述，如果在項目中的每個查詢的表后面都加nolock,這種做法并不科學，起碼特別費時間，不如行版本控制來的直接有效。而且會存在不可預期的技術問題。應該有選擇性的挑選最適合的表來放棄共享鎖的使用。
最后說下nolock和with(nolock)的幾個小區別：
1.SQL05中的同義詞，只支持with(nolock);
2.with(nolock)的寫法非常容易再指定索引。
【編輯推薦】
