문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 | ||
mssqlserver:performance [2018/08/27 17:54] kwon37xi |
mssqlserver:performance [2018/08/30 08:58] (현재) kwon37xi |
||
---|---|---|---|
줄 1: | 줄 1: | ||
====== SQLServer Performance ====== | ====== SQLServer Performance ====== | ||
* [[: | * [[: | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ===== 기본 ISOLATION Level ===== | ||
+ | SQLServer의 기본 Isolation Level은 **'' | ||
===== SSMS 에서 Execution Plan 보기 ===== | ===== SSMS 에서 Execution Plan 보기 ===== | ||
줄 10: | 줄 15: | ||
* '' | * '' | ||
+ | <code sql> | ||
+ | EXEC sys.sp_helpindex @objname = N' | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== No Lock ===== | ||
+ | |||
+ | ==== 왜 필요한가? | ||
+ | * SQL Server는 SELECT를 할 때 SHARED Lock을 건다. | ||
+ | * 이 상황에서는 다른 데서 SHARED Lock을 건 데이터는 읽을 수 있지만 UPDATE/ | ||
+ | * 또한 매우 실행 시간이 길고 폭넓은 데이터를 선택하는 SELECT 문 실행시에 SHARED Lock이 걸려 있으면 UPDATE/ | ||
+ | * 따라서 장시간 걸리고, 여러 행(row)을 탐색하는 SELECT 쿼리의 경우 '' | ||
+ | |||
+ | ==== 실행 방법 ==== | ||
+ | * [[http:// | ||
+ | * ISOLATION을 **'' | ||
+ | <code sql> | ||
+ | SELECT id | ||
+ | FROM table_a WITH (NOLOCK) | ||
+ | |||
+ | SELECT a.id, b.id | ||
+ | FROM table_a a WITH (NOLOCK), table_b b WITH (NOLOCK) | ||
+ | WHERE a.id=b.id | ||
+ | </ | ||
+ | |||
+ | ==== 문제점 ==== | ||
+ | * isolation level '' | ||
+ | * Dirty Reads : update 중이지만 아직은 commit이 안 된 데이터를 읽게됨. Rollback 시 데이터가 바뀌어버림. | ||
+ | * Phantom Reads : insert/ | ||
+ | * Nonrepeatable Reads : 동일 트랜잭션내에서 동일 쿼리로 데이터를 읽는데 결과가 달라질 수 있다. | ||
+ | * 결론적으로 | ||
+ | * **단건 쿼리 혹은 정합성이 중요한 쿼리에서는 사용하지 말 것** | ||
+ | * 실행시간이 긴 통계성 쿼리에서는 거의 필수적으로 필요함. | ||
+ | * CUD 트랜잭션을 짧게 가져갈 수 있도록 항상 노력할 것. | ||
+ | ===== UPDATE LOCK ===== | ||
+ | * [[http:// | ||
+ | * '' | ||
+ | * 따라서 대상 데이터 탐색시에는 UPDATE Lock을 걸고, 실제 업데이트 수행시 EXCLUSIVE Lock으로 변경한다. | ||
+ | |||
+ | |||
+ | ==== 참조 ==== | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// |