LINQ-TO-SQL에서는 성능을 향상시키기 위해 NOLOCK을 사용해야합니까?
-
15-11-2019 - |
문제
DBA는 LINQ 쿼리가 데이터베이스에 수천 개의 잠금을 생성하는 정보를 제공합니다. 우리 팀의 개발자는이 Hanselman Post를 우리의 문제에 대한 가능한 해결책으로 파견합니다 :
http://www.hanselman.com/blog/gettinglinqtosqlandlinqtoentitiestousenolock.aspx
Scott은 NOLOCK 설정을 위해 LINQ에서 3 가지 방법을 제공합니다. 1) Transactionscope (기본), 2) SPROCS, 3) Context.Executecommand
우리는 99 %의 읽기 뉴스 사이트로, 1 %의 쓰기 때문에 우리의 주요 초점은 검색 속도에 있습니다. NOLOCK 모든 LINQ-TO-SQL 쿼리에 대해 좋은 전략입니까?
내가 이해하려고하는 것은 이유는 무엇인가? NOLOCK를 사용하는 이유는 무엇입니까 아니면 좋은 생각이 아닙니다. 같은 목표를 가진 많은 사람들이 있어야합니다. 많은 빨리 읽습니다. NOLOCK이 명백한 답변이라면 왜 그렇지 않은 이유는 무엇입니까? 모든 단일 데이터 호출에서 설정 해야하는 대신 컨텍스트에서 기본값을 설정할 수없는 이유는 무엇입니까?
는 NOLOCK이 실제로 많은 빠른 읽기를위한 최상의 옵션이며, 몇 가지 업데이트 사이트가 있습니까?
업데이트 : SQL Server 2005 이상에서는 NOLOCK보다 스냅 샷 격리가 있습니까? 나는 이것을 발견했다 http://msdn.microsoft.com/en-us/library/ms179599.aspx. committed snapshot 을 다루는
. 이렇게하면 쓰기 블록을 방지하지만 더러운 데이터를 반환하지 않습니까? 이것은 NOLOCK을 통해 90 %의 시간의 90 %를 사용해야합니까?
업데이트 2 : 나를 괴롭 히는 것은 건조
나를 괴롭히는 부분은 잠금 장치 또는 스냅 샷 패턴을 구현하기 위해 모든 LINQ-TO-SQL 쿼리 메소드 (업데이트에서 사용되는 것 제외)에서 변경해야합니다. 이것은 건조한 주요 위반과 같은 냄새가납니다.
해결책
Worth noting: READ COMMITTED SNAPSHOT
is (or at least was 2+ years ago) good enough for the site you're using.