同事寫了個程序用創(chuàng)建多個線程使用ado同時對同個數(shù)據(jù)庫進行相同的查詢，涉及2張數(shù)據(jù)表的聯(lián)查。當線程數(shù)非常多的情況下，讀取數(shù)據(jù)的效率就會變得很慢，例如50個線程同時查詢大概3000條數(shù)據(jù)，查詢完成后通過游標全部讀取到本地需要大概30秒。單個線程可能就一兩秒。這是由于數(shù)據(jù)庫鎖導致的。

同樣的程序在我的機子上運行性能提高了1倍。主要原因由于我連接的sql server是企業(yè)版的，而同事那個連接的數(shù)據(jù)庫是開發(fā)版的，企業(yè)版的sql server對并發(fā)訪問做了一定的優(yōu)化。

但是這個性能還是不夠高。于是我嘗試去去除數(shù)據(jù)庫鎖。可以通過在查詢語句前面增加SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，或者在查詢語句的表名后面加上(nolock)。根據(jù)msdn的解釋，這兩種方式是一樣的，就是通過不加鎖的方式提高查詢效率，而導致的后果就是會查詢到未提交的事務的數(shù)據(jù)。不過由于所查詢的表格都是插入操作，所以不會有影響。第一種方式是針對整個查詢事務，而nolock是針對查詢的表格，所以如果使用nolock方式需要對每個表后面都加上（nolock）。但是實際測試的情況確實執(zhí)行SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED方式查詢效率有較大的改善，而使用nolock方式查詢效率基本不變。在網(wǎng)上找了很久還是沒有結果，希望有高手知道原因留個言，不勝感激。

再說說以上兩種方式，測試中第一種能夠提高查詢效率，但是由于程序使用的是ado的方式訪問數(shù)據(jù)庫，使用第一種方式會導致游標無法移動到特定位置，而只能向前移動。所以無法使用第一種方式。坑爹的ado，看來要盡快找到另一種數(shù)據(jù)庫訪問方式來替代ado，不然老是需要根據(jù)ado來更改數(shù)據(jù)庫設計。

SQL Server提高并發(fā)查詢效率