I ditt scenario skulle jag rekommendera att du uttryckligen ställer in isoleringsnivån till ögonblicksbild - det kommer att förhindra att läsning kommer i vägen för skrivningar (infogningar och uppdateringar) genom att förhindra låsningar, men dessa läsningar skulle fortfarande vara "bra" läsningar (d.v.s. inte smutsiga data - det är inte samma sak som en NOLOCK)
Generellt tycker jag att där jag har låsningsproblem med mina frågor, styr jag manuellt låset som tillämpas. t.ex. Jag skulle göra uppdateringar med radnivålås för att undvika låsning av sid-/tabellnivå, och ställa in mina läsningar till readpast (accepterar att jag kan missa vissa data, i vissa scenarier kan det vara ok) länk|redigera|radera|flagga
EDIT-- Kombinera alla kommentarer till svaret
Som en del av optimeringsprocessen undviker sql-servern att få engagerade läsningar på en sida som den vet inte har ändrats, och faller automatiskt tillbaka till en mindre låsningsstrategi. I ditt fall faller sql-servern från en serialiserbar läsning till en repeterbar läsning.
F:Tack för den användbara informationen om att sänka isoleringsnivåer. Kan du komma på någon anledning till att den skulle använda Serializable IsolationLevel i första hand, med tanke på att vi inte använder en explicit transaktion för SELECT - det var vår uppfattning att den implicita transaktionen skulle använda ReadCommitted?
S:Som standard kommer SQL Server att använda Read Commmited om det är din standardisoleringsnivå MEN om du inte anger en låsstrategi i din fråga, säger du i princip till sql-servern "gör vad du tycker är bäst, men jag föredrar är läst engagerad". Eftersom SQL Server är fritt att välja, så gör den det för att optimera frågan. (Optimeringsalgoritmen i sql-server är mycket komplex och jag förstår det inte helt själv). Att inte explicit exekvera inom en transaktion påverkar inte den isoleringsnivå som sql-servern använder.
F:En sista sak, verkar det rimligt att SQL Server skulle öka isoleringsnivån (och förmodligen antalet lås som krävs) för att optimera frågan? Jag undrar också om återanvändning av en poolad anslutning skulle påverka detta om den ärvde den senast använda isoleringsnivån?
S:SQL-servern kommer att göra det som en del av en process som kallas "Lock Escalation". Från http://support.microsoft.com/kb/323630 , jag citerar:"Microsoft SQL Server bestämmer dynamiskt när låseskalering ska utföras. När man fattar detta beslut tar SQL Server hänsyn till antalet lås som hålls på en viss genomsökning, antalet lås som hålls av hela transaktionen, och minnet som används för lås i systemet som helhet. Normalt resulterar SQL Servers standardbeteende i att låseskalering endast inträffar på de punkter där det skulle förbättra prestandan eller när du måste reducera överdrivet systemlåsminne till en mer rimlig nivå . Vissa program- eller frågedesigner kan dock utlösa låseskalering vid en tidpunkt då det inte är önskvärt, och det eskalerade tabelllåset kan blockera andra användare".
Även om låseskalering inte är exakt samma sak som att ändra isoleringsnivån som en fråga körs under, förvånar detta mig eftersom jag inte hade förväntat mig att sql-servern skulle ta fler lås än vad standardisoleringsnivån tillåter.