가늘어도 긴놈이 장땡

http://merritt.co.kr/tt/73 에서 인덱스 머지에 관한 기초적인 이야기를 썼는데, 1억건이 넘어가는 엄청나게 큰 테이블들에 조회조건이 굉장히 다양하게 들어올 때 인덱스 구조를 잡는 것이 상당한 고민이 된다.

이때 인덱스 머지 전략을 적절하게 사용하면 인덱스 길이를 최소화하면서 성능도 그렇게 떨어지지 않는 쿼리를 만들어낼 수 있다. 그러면 인덱스 머지를 어떻게 유도할 것이냐가 문제다. 대부분의 경우 서버가 알아서 실행계획을 세워준다지만, 힌트를 줘서 유도할 수 있으면 싶을 때도 있다.

SQL 서버에는 인덱스 머지라는 힌트는 없지만, index 를 여러개 지정함으로써 인덱스 머지 플랜을 유도할 수 있다. 자세한 것은 SELECT 문에 대한 BOL 의 설명을 자세히 읽어보면 된다.


이렇게 하면 ix_1 과 ix_2 를 각각 읽어서 clustered index key 를 이용한 join 을 수행하게 된다. 컬럼의 분포도와 선택성을 고려해서 여러가지로 테스트해보면 이런 전략이 유용할 때가 있다.

Posted by maceo

박노철
maceo.park@gmail.com
http://merritt.co.kr

다음 테이블을 생각해보자.


child.col1 은 parent.col1 이 non-identifying relation 으로 내려온 것이다. 이제 child 테이블에 대해서 insert 를 하나 해보자.



실행계획이 어떻게 나오는지 확인해보자.



뭔가 이상하지 않은가? child 에 insert 하는데 parent 쪽을 CIDX seek 을 한다. 생각해보면 너무 당연하다. FK 가 걸려있으므로 insert 하기 전에 일단 parent 쪽을 먼저 체크해봐야 한다. 또하나 재밌는 점은, 일단 Table Insert 가 이뤄진 후, Left Semi Join 을 해서 Assert 를 한다는 사실이다. 즉, 일단 일 저질러 놓고 Assert 로 체크해보고 실패하면 롤백한다. (관련된 이야기가 Inside SQL Server 2000 에 있는 것으로 기억되는데 가물가물하다...) delete 문도 마찬가지다.




parent 를 delete 하기 전에 child 에 FK로 내려간 데이터가 없나 찾아보고 있다. 그런데 이 실행계획은 심각한 문제를 가지고 있다. 바로 테이블 스캔을 한다는 사실이다. 자, 그렇다면 여기서 너무도 당연하지만 간과하기 쉬운 결론이 도출된다. FK가 존재하는 테이블에서는 FK로 내려간 컬럼이 맨앞에 나오는 인덱스를 무조건 걸자! 안그러면 뭐하나 delete, insert, update 할 때 마다 Index Scan 또는 Table Scan 이 날 수 있다.

Posted by maceo