[MSSQL] view nolock 힌트 테스트

Oracle, MySQL, PostgreSQL등과 다르게 특이한 형태의 MVCC를 사용하는 MSSQL

MSSQL을 접한지 15년이 넘었지만 아무래도 MS의 가장 큰 패착이었을것으로 보이는 아키텍처

 

그로 인해 이런 테스트도 해본다.

당연히 이러하겠지라는 결과이지만 추정보단 확실한 확인이 엔지니어의 기본 소양이므로..

 

Version : SQLServer 2014

 

* 테스트 준비

-- 테스트 테이블 및 뷰 생성
drop table t1
go
create table t1 (c1 int)
go
insert into t1 (c1) values (100), (200)
go

drop view v_t1
go
create view v_t1
as
    select *
      from t1
go

drop view v_t1_nolock
go
create view v_t1_nolock
as
    select *
      from t1 with(nolock)
go

 

* 테스트 시작

-- session 1
-- 기본 isolation level인 read committed

-- lock 잡기
begin tran

update t1 set c1 = 999 where c1 = 100;

 

-- session 2
-- 기본 isolation level인 read committed

-- 힌트 없이 테이블 직접 select
select *
  from t1;
-- 당연히 lock waiting

-- nolock 힌트 사용된 view select
select *
  from v_t1_nolock;
-- 999
-- 200
-- dirty read로 조회 성공

-- nolock 힌트 없는 view select
select *
  from v_t1;
-- lock waiting


-- nolock 힌트 없는 view에 with(nolock) 조회
select *
  from v_t1 with(nolock)
-- 999
-- 200
-- dirty read로 조회 성공

-- 반대로 nolock 힌트 사용된 view에 with(rowlock) 조회
select *
  from v_t1_nolock with(rowlock)
-- 메시지 4138, 수준 16, 상태 1, 줄 22
-- 테이블 "t1"에 지정된 잠금 힌트가 충돌합니다. 뷰에 지정된 힌트가 충돌하여 이러한 문제가 발생할 수 있습니다.
-- 오.. 충돌 에러 발생

 

* 결과

마지막 nolock 힌트를 사용해 생성된 뷰에 with(rowlock) 힌트를 이용해 SELECT 하는 경우가

가장 궁금했었는데 에러처리가 되도록 해둔것을 알 수 있었다.

 

기본적으로 뷰 사용을 지양하는 편이라 쓸 일은 거의 없었지만

뷰를 좋아하시는 개발자분들이 많으므로 종종 접할 수 밖에 없어서 테스트 해보았는데

 

만약 뷰를 사용한다면 with(nolock)과 같은 isolation level을 조정시키는 힌트는 뷰안에는 넣지 말고

뷰를 호출하는 쪽에서만 컨트롤하는것이 효율적으로 판단된다.

 

하지만.. 뷰는 남발하지 마세요.. ㅠㅠ