저는 SQL Server를 처음 접했고 다음과 같은 매우 간단한 select
명령문이 잠금을 수행하는지 이해하고 싶습니다 .
Select * from Student;
명령문이 begin tran
블록 내에서 실행되지 않는 경우를 고려하십시오 .
저는 SQL Server를 처음 접했고 다음과 같은 매우 간단한 select
명령문이 잠금을 수행하는지 이해하고 싶습니다 .
Select * from Student;
명령문이 begin tran
블록 내에서 실행되지 않는 경우를 고려하십시오 .
답변:
예. 기본적으로 읽은 행에서 공유 잠금을 사용합니다 (읽을 클러스터 된 인덱스의 모든 페이지에서 의도 공유 잠금도 사용함). 더티 읽기를 방지하기 위해 수행됩니다. 그러나 이것을 우회하는 방법이 있습니다 (SQL Server에는 nolock 힌트가 있습니다). 명령문이 BEGIN TRAN에 없으면 SELECT 문이 실행 된 후 잠금이 해제됩니다.
자세한 정보는 여기에서 찾을 수 있습니다.
http://msdn.microsoft.com/en-us/library/ms184286(v=sql.105).aspx http://www.sqlteam.com/article/introduction-to-locking-in-sql-server
다음의 매우 간단한 select 문이 잠금을 수행하는지 여부를 이해하고 싶습니다.
기본 트랜잭션 격리 수준 에서 실행 되는 쿼리 가 더티 읽기를 방지하기 위해 항상 공유 잠금을 사용 한다는 것은 일반적인 오해 입니다 .SELECT
READ COMMITTED
커밋되지 않은 데이터가 없으면 커밋되지 않은 데이터를 읽을 위험이없는 경우 SQL Server는 공유 행 수준 잠금을 피할 수 있습니다 (높은 수준의 Intent-Shared (IS) 잠금은 여전히 사용됨).
공유 행 잠금 이 수행 되더라도 (아마 다른 동시 트랜잭션이 행이있는 페이지를 수정했기 때문에) SELECT
명령문이 완료 되기 오래 전에 해제 될 수 있습니다 .
대부분의 경우 서버가 다음 행을 처리하기 직전에 행이 '잠금 해제'됩니다. 기본 분리 레벨에서 수행 된 공유 잠금이 현재 명령문의 끝에 있지만 트랜잭션 의 끝에는없는 상황이 있습니다 .
NOLOCK
테이블 힌트로 현재 격리 수준을 재정의하는 것은 거의 항상 나쁜 생각 입니다.
잠금은 구현 세부 사항입니다. SQL Server는 현재 격리 수준 에서 제공하는 의미 보장을 충족시키기 위해 필요할 때 잠금을 수행 합니다 . 잠금이 수행되는 이유에 대해 조금 아는 것이 도움이되는 경우가 있지만, 예측을 시도하는 것은 종종 비생산적입니다.
SQL Server는 다양한 격리 수준을 제공합니다. 데이터 소비자에게 필요한 보장과 행동을 제공하는 것을 선택하십시오.