SQL 서버 사용 중 Query 나 DML 이 인덱스 사용을 비 정상적으로 할 때...

SQL 스키마 구조에서 가장 중요한 것이 무어냐고 묻는다면, 단연 인덱스의 효율성이라 이야기 할 수 있다.

 

 아무리 많은 Data 가 증가할 지라도, 인덱스를 효율적으로 사용하는 쿼리는 이론상 속도의 저하가 발생하지 않는다.

 

 RDBMS 상에서 Data 가 늘어 가는 것은 오히려 당연한 이치이고, 아무리 많은 Data 가 증가할 지라도, 인덱스를 효율적으로 사용하는 쿼리는 이론상 속도의 저하가 발생하지 않는다. (백업이나 Data 관리의 부하가 증가하는 것은 다른 문제로 하자.)

 

 그런데, 정말 잘 만든 인덱스를 타지 않는 쿼리가 있다면... 성능에 심각한 문제를 발생하게 될 것이다.

 문제는 두가지다.

 우리가 잘못했거나...

 MS 의 최적화기가 잘못 동작하거나....

 

대부분의 경우 최적화기가 오동작을 하는 것은 이유가 있다.

 

 MS 의 입장에서는 최적화기의 오동작을 염두에 두고 있기에 Hint 라는 것을 제공한다. 하지만, 대부분의 경우 최적화기가 오동작을 하는 것은 이유가 있다. 통계가 잘못 되었다거나, 인덱스의 단편화가 너무 심하다거나...

 그런 저런 정보를 다 분석한 이후에도 악성 쿼리를 찾았는데... 그 쿼리가 정상적인 인덱스를 타고 있지 않다면...?

( 악성 쿼리를 찾는 법은 아래를 참조..

http://masterjoe.tistory.com/entry/MS-SQL-병목-탐지)

 

 쿼리 또는 DML 에 사용되는 자료형을 의심해볼 필요가 있다.

 스키마나 Data 모델링은 매우 숙련된 DBA 가 진행할지라도, 적지 않는 경우 Stored procedure 이외에 웹 페이지 상에서 Ad-hoc 으로 날리는 SQL 이 적지 않고, 이 경우 개발 템플릿을 벗어나서 작성되는 경우가 매우 많다. 특히 템플릿에 자료형을 nvarchar 나 varchar  로 설정하고 크기도 약 (4000) 이상을 적용하는 경우가 적지 않다.

 

SQL 서버는 접근하는 자료형을 규칙이 따라 임의로 해석하기 때문에 전혀 엉뚱한 인덱스를 참조하거나 TABLE Scan 을 수행하는 경우가 발생한다.

 

 이 경우 SQL 서버는 접근하는 자료형을 규칙이 따라 임의로 해석하기 때문에 전혀 엉뚱한 인덱스를 참조하거나 TABLE Scan 을 수행하는 경우가 발생한다. 둘 다, 치명적인 영향을 미치며, 이로 인하여 추가적인 query  에 대하여 시스템의 응답 불가의 상황까지 발생하게 되는 경우가 발생한다.

 

 따라서 Table 에 선언된 자료형와 동일한 형식의 자료형의 사용이 매우 중요하다.

 

 먼저 인덱스가 정상적인지, 제대로 구성되었는지 분석하고, 그 이후에도 문제가 발생하면, 단편화가 없는지 보자, 그래도 계속 문제가 생기면... 혹시나 그렇지 않겠지만, 자료형을 꼭 참고하도록 하자. 특히 개발자의 경력이 짧거나, 납기가 촉박해서 기능 구현에 쫓기는 경우 더더욱 주의해서 보아야 한다.