SP 검수 시 체크해야 할 리스트

SP 검수 시 체크해야 할 리스트

---

 

* SQL Server 기준으로 작성하였습니다.

 

1. Ad-hoc, 동적 쿼리 제거

1. Ad-hoc, 동적 쿼리는 실행 시 쿼리가 어떻게 구성되는지 알 수 없습니다.

   구성을 알 수 없으면 인덱스가 적절하게 구성되었는지, 실행계획이 잘못풀려 악성쿼리인지 아닌지를 판단할 수 없습니다.

 

 

2. where 절 체크 사항

1. 동일한 데이터 타입끼리 비교되는지 확인합니다.

   서로다른 데이터 타입끼리 비교 시 CONVERT 함수가 사용되기 때문에 인덱스 사용을 할 수 없습니다.

2. OR 문은 UNION ALL 로 변경

   OR 문은 상황에 따라 Scan 으로 풀릴 가능성도 있습니다.

   UNION ALL 로 쿼리를 Seek + Seek 하는 방식으로 변경이 가능한지 확인합니다.

3. CASE 문은 분기처리로 변경

   처음 쿼리가 실행될 때의 CASE 조건으로 실행계획이 풀리게 됩니다.

   이 후 CASE 절의 다른 조건으로 실행되는 경우 처음 설정된 실행계획을 계속사용하면서 잘못된 실행계획으로 풀릴 수 있습니다.

   CASE 문을 IF 분기처리하여 하나의 조건절로만 풀릴 수 있도록 가능한지 확인합니다.

4. NOT 구문이 사용되지는 않았는지 확인합니다.

5. OLTP 인 경우 전체 데이터를 조회하게 하는 조건이 없는지 확인합니다.

 

 

3. 조인을 사용한 경우 ANSI 조인 및 적절한 조인방식이 사용되었는지 확인

1. OLTP 인 경우 보통은 NL 조인을 사용

 

 

4. 조회 시 * 가 사용되었는지 확인

1. * 는 불필요한 데이터를 조회하여 리소스를 더 많이 사용하게 됩니다.

2. * 를 사용하는 경우 이후 테이블의 컬럼이 추가되거나 제거되면서 이슈가 발생할 가능성이 있습니다.

 

 

5. 대량 조회를 해야하는 경우 Paging 이나 TOP 으로 데이터를 제한

1. TOP 에 변수처리가 가능한데 이런 경우 데이터 조회 제한 건수를 알 수 없습니다. TOP 에는 변수를 사용하지 말아야 합니다.

2. Paging 의 경우에도 읽기 수를 제한하는 기법으로 가이드 할 수 있어야 합니다.

   Paging 은 https://mozi.tistory.com/312 링크를 참조하도록 합니다.

 

 

6. 리소스 사용 제한

1. 백오피스나 배치성 쿼리의 경우 OPTION (MAXDOP 1) 을 부여하여 서비스 리소스에 부하를 최소화 시켜야 합니다.

 

 

7. Lock 레벨에 대해 확인

1. 서비스에 사용되는 DML 에서 TAB Lock 이 발생할 수 있는 이슈가 없는지 확인합니다.

2. 조회 쿼리에서 WITH(NOLOCK) 이 사용되었는지 확인합니다.

 

 

8. 서비스에 사용되는 DML 의 경우 확인사항

1. DML 의 조건절 인덱스가 PK 이거나 UK 인지 확인합니다.

   PK, UK 가 아닌 경우 테이블의 전체 데이터가 쿼리대상에 포함되는지 개발팀에 확인합니다.

2. 배치성인 경우에는 단위처리로 하도록 합니다.

 

 

9. 임시 테이블이나, 커서는 사용하지 않도록

1. 임시 테이블, 커서는 자원을 많이 사용합니다.

   커서 대신 Identity 테이블을 사전에 생성하여 재활용 할 수 있도록 합니다.

 

 

10. 스키마 명시

1. owner 스키마에서 객체 검사 후 없는 경우 dbo 스키마에서 객체가 있는지 재검색합니다.

   재검색하는 비효율을 제거할 수 있도록 합니다.

 

 

11. 쿼리 실행계획 확인

SP 에서 사용된 쿼리 실행계획에 문제가 없는지 확인합니다.

 

 

 

 

SP 가 잘못 되면 서비스에서 장애가 발생하게 됩니다.

꼼꼼하게 검사하여 안정적인 서비스를 운영할 수 있도록 합니다.