1 EXISTS ~ UPDATE ~ INSERT 패턴이란?

2 무엇이 문제인가?

3 결론

어쩌다가 보니 성능에 영향을 끼치는 패턴이 발견되어 정리해보았다. 이 패턴은 게임업체 뿐만 아니라 제조, 병원, 대학 등의 여러 업종에서 전반적으로 발견되는 패턴이다. 이름 붙이기는 싫었지만 글이 길어지므로 'EXISTS ~ UPDATE ~ INSERT패턴'이라고 이름을 붙여 보았다. 투입되는 리소스에 비해서 얻는 이득이 많은 유형이다.

문제는 라인 1의 코드다. 우선 EXISTS 사용시 ‘SELECT ID FROM …’은 현재로써는 문제가 없지만 SELECT절에 ID가 아닌 어떤 다른 컬럼를 명시하게 된다면 랜덤액세스(Bookmark Lookup)이 발생하여, 추가적인 비용이 생길 수 있다. 그러므로 EXISTS 사용시는 ‘SELECT TOP 1 * FROM …’또는 ‘SELECT TOP 1 1 FROM…’과 같이 사용하여야 한다. 이는 추가적인 비용이 발생할 가능성이 있는 부분이다. 진짜 문제는 1라인 자체가 존재하지 않아도 되지만 존재하고 있어 추가적인 비용이 발생하고 있는 것이다.

UPDATE, DELETE연산에는 SELECT가 포함되어 있다. 그러므로 위와 같이 UPDATE 후 UPDATE된 데이터가 없으면 INSERT하는 것으로 종료될 수 있다. 코드의 복잡성도 줄고, 라인수도 줄었다.

개별적인 SP로 본다면 정말 빠른 SP다. 하지만 SP가 실행되는 곳은 서버다. 특히나 포털의 고객 인증을 담당하는 DB서버와 같이 많은 Request가 발생하는 곳에서라면 이러한 불필요한 조회는 성능에 큰 영향을 끼치게 된다. 초당 존재여부를 묻는 코드가 100회 실행된다면 최소한 하루에 17280000 만큼의 불필요한 I/O가 발생하게 된다. 아마도 ‘존재하면 업데이트하고 존재하지 않으면 인서트하는’의 로직이면 많은 SP가 이렇게 개발되었을 것이다. 이러한 SP가 여러 곳에 존재한다. 아주 간단한 수정만으로도 많은 효과를 볼 수 있으므로 검토해 보기 바란다.