나는 업무에 중요 하지 않은 웹 사이트 및 응용 프로그램을 만드는 사업을하고 있습니다 . 뱅킹 소프트웨어, 우주 비행, 중환자 실 모니터링 애플리케이션 등 아이디어를 얻을 수 있습니다.
그래서, 그 거대한 면책 조항과 함께 일부 SQL 문에서 NOLOCK 힌트를 사용하는 것이 나쁘습니까? 몇 년 전에 동료 Sql 관리자가 “더티 읽기”에 만족하면 NOLOCK을 사용해야한다고 제안했습니다. “더티 읽기”에 만족하면 각 읽기가 잠금을 해제하지 않기 때문에 시스템 성능이 조금 더 향상됩니다. 테이블 / 행 / 무엇이든.
또한 교착 상태가 발생하는 경우 훌륭한 솔루션이라고 들었습니다. 그래서 Sql 전문가가 임의의 코드로 나를 돕고 SQL 코드에서 모든 NOLOCKS를 발견 할 때까지 몇 년 동안 그 생각을 따르기 시작했습니다. 나는 정중하게 꾸짖었고 그는 그것을 나에게 설명하려했고 (왜 그것이 좋지 않은지) 나는 길을 잃었습니다. 나는 그의 설명의 본질이 ‘더 심각한 문제에 대한 반창고 해결책이다. 특히 당신이 교착 상태를 경험하고 있다면 .. 따라서 문제의 근원을 수정하십시오. ‘
최근에 인터넷 검색을했고이 게시물을 보았습니다 .
그래서, 일부 SQL DB 전문가 선생님이 나를 계몽시켜 줄 수 있습니까?
답변
NOLOCK 힌트를 사용하는 경우 SELECT문의 트랜잭션 격리 수준 은 READ UNCOMMITTED입니다. 이것은 쿼리가 더럽고 일관성이없는 데이터를 볼 수 있음을 의미합니다.
일반적으로 적용하는 것은 좋은 생각이 아닙니다. 이 더티 읽기 동작이 미션 크리티컬 웹 기반 애플리케이션에 대해 정상인 경우에도 NOLOCK 스캔은 잠금 보호 부족으로 인해 데이터 이동으로 인해 쿼리를 종료하는 601 오류를 유발할 수 있습니다.
내가 읽어 보시기 바랍니다 스냅 샷 격리는 데 도움이되면하고 아파하는 경우 -은 MSDN은 READ 대부분의 상황에서 스냅보다는 스냅 샷을 COMMITTED 사용하는 것이 좋습니다.
답변
스택 오버플로 작업을하기 전에, 나는 반대했다 NOLOCK당신이 잠재적를 수행 할 수있는 원금 SELECT과 NOLOCK날짜 또는 일관성이 밖으로 할 수있는 데이터와 결과를 다시 얻을. 고려해야 할 요소는 다른 프로세스가 동일한 테이블에서 데이터를 선택할 수있는 동시에 삽입 / 업데이트 될 수있는 레코드 수입니다. 이런 일이 많이 발생하면 .NET과 같은 데이터베이스 모드를 사용하지 않는 한 교착 상태가 발생할 가능성이 높습니다 READ COMMITED SNAPSHOT.
이후 대량으로로드 된 SQL Server에서 교착 상태를 제거 NOLOCK하고 SELECT성능을 향상시킬 수있는 방법 을 확인한 후 사용에 대한 관점을 변경 했습니다 . 데이터가 정확히 100 % 커밋되지 않았고 결과가 오래 되었더라도 신속하게 결과를 되 찾아야하는 경우가 있습니다.
다음을 사용할 때 스스로에게 질문하십시오 NOLOCK.
내 쿼리에 많은 수의
INSERT/UPDATE명령 이있는 테이블이 포함 되어 있으며 쿼리에서 반환 된 데이터가 주어진 순간에 이러한 변경 사항을 누락 할 수 있는지 여부를 신경 쓰나요?
대답이 아니오이면을 사용 NOLOCK하여 성능을 향상 시키십시오.
방금 NOLOCKStack Overflow의 코드베이스 에서 키워드를 빠르게 검색 하고 138 개의 인스턴스를 찾았으므로 꽤 많은 곳에서 사용합니다.
답변
더티 읽기에 신경 쓰지 않는다면 (즉, 주로 READ 상황에서) NOLOCK괜찮습니다.
그러나 대부분의 잠금 문제는 쿼리 워크로드에 대한 ‘올바른’인덱스가 없기 때문입니다 (하드웨어가 작업에 달려 있다고 가정).
그리고 전문가의 설명이 정확했습니다. 일반적으로 더 심각한 문제에 대한 반창고 솔루션입니다.
편집 : 나는 확실히 NOLOCK을 사용해야한다고 제안하지 않습니다. 나는 분명히 그것을 분명히 했어야한다고 생각한다. (나는 그것이 괜찮다고 분석 한 극한 상황에서만 그것을 사용할 것입니다). 예를 들어, 얼마 전에 잠금 문제를 완화하기 위해 NOLOCK이 뿌려진 TSQL을 작업했습니다. 나는 그것들을 모두 제거하고 올바른 인덱스를 구현했으며 모든 교착 상태가 사라졌습니다.
답변
트래픽이 많은 경험이있는 “전문가”는 의심 스럽습니다.
웹 사이트는 일반적으로 사용자가 완전히로드 된 페이지를 볼 때 “더럽습니다”. 데이터베이스에서로드 한 다음 편집 된 데이터를 저장하는 양식을 고려해보십시오. 사람들이 더러운 읽기에 대해 그렇게하는 방식은 멍청합니다.
즉, 선택 항목에 여러 레이어를 구축하는 경우 위험한 중복으로 구축 할 수 있습니다. 돈이나 상태 시나리오를 다루는 경우 트랜잭션 데이터 읽기 / 쓰기뿐만 아니라 적절한 동시성 솔루션 (대부분의 “gurus”가 신경 쓰지 않는 것)이 필요합니다.
반면에 웹 사이트에 대한 고급 제품 검색 (예 : 캐시되지 않을 가능성이 높고 약간 집약적 일 가능성이있는 항목)이 있고 동시 사용자가 몇 명 이상인 사이트를 구축 한 적이 있다면 (놀랍게도 “전문가”는 그렇지 않습니다), 그 뒤에있는 다른 모든 프로세스를 병목하는 것은 우스꽝 스럽습니다.
그것이 의미하는 바를 알고 적절할 때 사용하십시오. 오늘날 데이터베이스는 거의 항상 주요 병목이 될 것이며 NOLOCK 사용에 대해 현명하면 인프라에서 수천을 절약 할 수 있습니다.
편집 : 그것은 단지 교착 상태가 아니라 당신이 끝낼 때까지 다른 사람들을 얼마나 기다리게 할 것인지 또는 그 반대의 경우도 마찬가지입니다.
답변
잘못된 대답은 없지만 약간 혼란 스러울 수 있습니다.
- 단일 값 / 행을 쿼리 할 때는 항상 NOLOCK을 사용하는 것이 좋지 않습니다. 잘못된 정보를 표시하거나 잘못된 데이터에 대해 조치를 취하지 않을 수도 있습니다.
- 대략적인 통계 정보를 표시 할 때 NOLOCK은 매우 유용 할 수 있습니다. 예를 들어 SO 가지고 : 읽기 잠금을 취할 말도 안되는 것입니다 정확한 질문이나 태그에 대한 질문의 정확한 수의 전망의 수입니다. 지금은 “sql-server”로 태그가 지정된 3360 개의 질문을 잘못 설명하고 트랜잭션 롤백으로 인해 1 초 후에 3359 개의 질문이 표시되는 경우 아무도 신경 쓰지 않습니다.
답변
전문 개발자로서 저는 상황에 따라 다릅니다. 하지만 저는 확실히 GATS와 OMG Ponies의 조언을 따릅니다. 당신이하는 일을 알고, 그것이 언제 도움이되는지, 언제 아프고,
SQL 서버를 더 깊이 이해하게 만들 수 있습니다. 나는 일반적으로 SQL 힌트가 사악하다는 규칙을 따르지만, 불행히도 가끔씩 SQL 서버를 강제하는 데 지칠 때마다 사용합니다. 그러나 이것은 드문 경우입니다.
루크
답변
앱 지원이 SSMS (보고를 통해 제공되지 않음)를 사용하여 프로덕션 서버의 ad-hock 쿼리에 응답하고 싶을 때 nolock을 사용하도록 요청했습니다. 이렇게하면 ‘주요’사업이 영향을받지 않습니다.
