當對資料庫中的資料進行讀操作或修改時,資料庫引擎使用專門的控制類型來保持資料庫的完整性,稱為鎖機制。鎖機制通過確保包含在一個事務中的資料庫記錄在該事務提交之前不能被其它事務修改來保證資料庫的一致性。
在設計資料庫應用時,你應該記住各種不同類型的鎖及事務發生的不同隔離等級。通常情況下,SQL Server預設能夠很好地完成你要使用的功能,不過,有些時候利用SQL語句在資料表上手工添加關於鎖是如何應用的提示資訊將是十分有用的。
本文主要介紹了兩種資料表提示:NOLOCK和READPAST。我們將建立一個資料表用作例子中的查詢資料表。執行列表A中的指令碼建立一個SalesHistory資料表並添加一些資料。
NOLOCK
該資料表提示,也稱為READUNCOMMITTED,只能用於SELECT語句。NOLOCK表明沒有對資料表添加共用鎖定以阻止其它事務對資料表資料的修改。
該語句的好處是它可以使資料庫引擎不用在處理查詢中的上鎖問題,可以提高並發性並改善資料庫效能,因為資料庫引擎不用在維護共用鎖定的使用問題。存在的問題是因為該語句不能處理要讀取的資料表的所有鎖,所以一些“髒資料”或未被提交的資料潛在的可能被讀取。
如果某個事務被滾回,那麼應用了NOLOCK串連的資料讀取操作將可以讀取未提交的資料。這種類型的讀取導致處理的不一致性會帶來很多問題。這是你使用NOLOCK時應該瞭解的技巧。
作為一個負面影響,NOLOCK查詢還可能帶來讀取“幻影”資料或讀取在一個資料庫讀取事務中可以獲得的但在另一個事務中可能被滾回的資料的風險。(我將在本系列文章的第二部分對這個負面影響進行詳細說明。)
下面的例子展示了NOLOCK如何工作以及髒資料讀取是如何產生的。在下面的指令碼中,我用一個事務在SalesHistory資料表中插入一條記錄。
BEGIN TRANSACTION
INSERT INTO SalesHistory
(Product, SaleDate, SalePrice)
VALUES
('PoolTable', GETDATE(), 500)
這個事務仍舊是開放的,這意味著仍可以對插入資料表的記錄上鎖以阻止其它操作。在一個新的查詢時段中,運行下面的指令碼,該指令碼使用NOLOCK資料表提示返回SalesHistory資料表中的記錄數。
SELECT COUNT(*) FROM SalesHistory WITH(NOLOCK)
返回記錄數值為301。因為對SalesHistory資料表插入記錄的事務還沒有提交,所以我們可以撤銷它。我通過使用下面的語句將事務滾回:
ROLLBACK TRANSACTION
該語句從SalesHistory資料表中刪除前面插入的記錄。現在我們運行前面啟動並執行同樣的SELECT語句。
SELECT COUNT(*) FROM SalesHistory WITH(NOLOCK)
這次返回記錄數的值為300。我第一次查詢讀記錄的事務還沒有提交,這就是一個髒資料讀取。