간단한 선택 쿼리가 잠금을 획득합니까?


14

저는 SQL Server를 처음 접했고 다음과 같은 매우 간단한 select명령문이 잠금을 수행하는지 이해하고 싶습니다 .

Select * from Student;

명령문이 begin tran블록 내에서 실행되지 않는 경우를 고려하십시오 .


1
생각보다 훨씬 복잡한 질문입니다. 대답은 여러 가지 (세션 트랜잭션 격리 레벨은 무엇입니까? 읽기 커밋 된 스냅 샷 격리가 켜져 있습니까? 스캔 된 인덱스에 행 또는 페이지 잠금을 방지하기위한 옵션이 설정되어 있습니까?)에 따라 달라지며 명령문 실행 중에도 변경 될 수 있습니다 (얼마나 많은 행이 테이블에 있습니까? 테이블이 분할되어 있습니까?). 다음 은 읽기 시작하기에 좋은 점입니다.
Jon Seigel

답변:


5

예. 기본적으로 읽은 행에서 공유 잠금을 사용합니다 (읽을 클러스터 된 인덱스의 모든 페이지에서 의도 공유 잠금도 사용함). 더티 읽기를 방지하기 위해 수행됩니다. 그러나 이것을 우회하는 방법이 있습니다 (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


또한 트랜잭션 격리 수준을 커밋되지 않은 읽기로 설정할 수도 있습니다.
Zane

1
따라서 SELECT가 10 개의 행을 읽는 경우 10 개의 행이 모두 읽힐 때까지 10 개의 공유 잠금이 유지됩니까?
Ian Warburton

26

다음의 매우 간단한 select 문이 잠금을 수행하는지 여부를 이해하고 싶습니다.

기본 트랜잭션 격리 수준 에서 실행 되는 쿼리 가 더티 읽기를 방지하기 위해 항상 공유 잠금을 사용 한다는 것은 일반적인 오해 입니다 .SELECTREAD COMMITTED

커밋되지 않은 데이터가 없으면 커밋되지 않은 데이터를 읽을 위험이없는 경우 SQL Server는 공유 행 수준 잠금을 피할 수 있습니다 (높은 수준의 Intent-Shared (IS) 잠금은 여전히 ​​사용됨).

공유 행 잠금 수행 되더라도 (아마 다른 동시 트랜잭션이 행이있는 페이지를 수정했기 때문에) SELECT명령문이 완료 되기 오래 전에 해제 될 수 있습니다 .

대부분의 경우 서버가 다음 행을 처리하기 직전에 행이 '잠금 해제'됩니다. 기본 분리 레벨에서 수행 된 공유 잠금이 현재 명령문의 끝에 있지만 트랜잭션 의 끝에는없는 상황이 있습니다 .

NOLOCK테이블 힌트로 현재 격리 수준을 재정의하는 것은 거의 항상 나쁜 생각 입니다.

잠금은 구현 세부 사항입니다. SQL Server는 현재 격리 수준 에서 제공하는 의미 보장을 충족시키기 위해 필요할 때 잠금을 수행 합니다 . 잠금이 수행되는 이유에 대해 조금 아는 것이 도움이되는 경우가 있지만, 예측을 시도하는 것은 종종 비생산적입니다.

SQL Server는 다양한 격리 수준을 제공합니다. 데이터 소비자에게 필요한 보장과 행동을 제공하는 것을 선택하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.