SQL 쿼리 속도를 높이는 9가지 방법

SQL은 데이터베이스 개발과 쿼리에 가장 많이 사용되는 언어지만 난해한 부분도 있다. 이럴 때 참고할 수 있는 빠른 SQL 쿼리를 쓰기 위한 9가지 모범 사례가 있다.
 

• 필요한 열만 불러오기 
• 조건부 열 업데이트에는 UPDATE 대신 CASE 사용 
• 큰 테이블 쿼리는 최소한으로 유지 
• 데이터 사전 준비(pre-stage) 
• 삭제와 업데이트는 일괄로 수행 
• 임시 테이블을 사용해 커서 성능 개선 
• 스칼라 함수보다는 테이블-값 함수 사용 
• 파티셔닝을 사용하여 큰 데이터 이동 방지 
• 성능을 위해서는 저장 프로시저 사용, 편리함을 위해서는 ORM 사용 

하나씩 자세히 살펴보자.
 

필요한 열만 불러오기 

필요한 모든 열을 나열하는 작업은 귀찮기 때문에 SQL에서는 습관적으로 SELECT *를 사용한다. 시간이 지나면서 열이 변경될 수도 있으니 그냥 쉬운 방법을 선호할 만도 하다. 그러나 100개 이상 열이 있는 테이블의 모든 열을 쿼리하면 어떻게 될까? 당장 시스템 전체에 부담이 될 가능성이 크다. 이와 같은 대규모 열은 사실 우울할 만큼 자주 마주치게 된다. 또한 더 적절한 스키마로 손을 보기가 불가능한 경우도 있다. 때로는 열의 하위 집합을 선택해 다른 쿼리에서 리소스 부족에 시달리지 않도록 하는 것이 이 골칫거리를 다루는 유일한 방법이다. 정리하면 쿼리를 프로토타이핑하는 단계에서는 SELECT *를 사용해도 무방하지만 업무용 환경에서는 실제로 사용되는 열만 요청해야 한다. 
 

조건부 열 업데이트에는 UPDATE 대신 CASE 사용 

개발자가 자주 하는 또다른 행동은 UPDATE ... WHERE를 사용해 다른 열의 값을 기반으로 한 열의 값을 설정하는 것이다. 다음과 같은 코드가 대표적이다.
 
이 방법은 간단하고 직관적이지만 경우에 따라 불필요한 문제가 발생할 수 있다. 예를 들어 테이블에 데이터를 삽입한 다음 위와 같이 UPDATE를 사용해 이 값을 변경하면 2개의 개별적인 트랜잭션이 된다. 행이 수백만 개 있는 경우 부가적인 트랜잭션은 많은 불필요한 작업을 유발한다. 따라서 이런 대규모 작업에서 더 좋은 방법은 쿼리에 인라인 CASE 문을 사용해 삽입 작업 자체가 이뤄지는 동안 열 값을 설정하는 것이다. 이렇게 하면 초기 삽입과 수정된 데이터를 한 번의 패스로 처리할 수 있다. 
 

큰 테이블 쿼리는 최소한으로 유지 

테이블에 대한 쿼리는 테이블의 크기와 상관없이 공짜가 아니다. 행 수가 수억 또는 수십억 개에 이르는 테이블에 대한 쿼리라면 더욱 그렇다. 따라서 할 수 있다면 큰 테이블에 대한 쿼리는 가능한 한 최소한의 개별 작업으로 통합해야 한다. 예를 들어 테이블에서 먼저 한 열로 쿼리한 후 다른 열로 쿼리하는 경우 먼저 하나의 쿼리로 병합한 다음 쿼리하는 열에 커버링 인덱스가 있는지 확인한다. 큰 테이블에서 똑같은 데이터 하위 집합을 가져와 이를 대상으로 작은 여러 쿼리를 실행하는 경우 이 하위 집합을 다른 곳에 보관하고 쿼리하면 자기 자신은 물론 다른 사람의 작업 속도도 높일 수 있다.
 

데이터 사전 준비

앞의 팁과 이어지는 내용이다. 예를 들어 기업에서 한 사람 혹은 여러 사용자가 여러 개의 큰 테이블을 조인해 많은 데이터를 집계해야 하는 보고서 또는 저장 프로시저를 주기적으로 실행한다고 하자. 매번 조인을 다시 실행하는 대신 이를 용도에 맞게 테이블에 “사전 준비(pre-stage)”하면 모든 사람의 수고를 상당부분 덜 수 있다. 이 테이블을 대상으로 보고서 또는 프로시저를 실행할 수 있으므로 공통적인 작업을 한 번만 수행하면 되기 때문이다. 리소스가 있고 데이터베이스가 지원한다면 인메모리 테이블을 사용해 속도를 더 높일 수 있다. 
 

삭제와 업데이트는 일괄로 수행 

행이 수십억 개인 테이블이 있는데 여기서 수백만 개의 행을 제거해야 한다고 하자. 단순한 방법은 그냥 트랜잭션에서 DELETE를 실행하는 것이다. 그러나 이렇게 하면 트랜잭션이 완료될 때까지 전체 테이블이 잠긴다. 더 세련된 방식은 삭제 또는 업데이트 작업을 다른 항목과 인터리빙할 수 있는 일괄(batch) 작업으로 수행하는 것이다. 각 트랜잭션은 더 작아지고 관리하기 쉬워지며, 작업 도중과 전후에 다른 작업을 수행할 수 있다. 애플리케이션 측면에서도 유리하다. 세션 전반에서 작업 진행 상황을 추적하고 이를 우선순위가 낮은 백그라운드 작업으로 수행할 수 있기 때문이다.
 

임시 테이블을 사용해 커서 성능 개선 

대부분의 경우 커서는 피해야 한다. 커서는 속도가 느리고 다른 작업을 차단하기 때문이다. 대신 커서로 할 수 있는 작업 대부분을 다른 방법으로 할 수 있다. 그러나 어떤 이유로든 커서를 사용할 수밖에 없다면 임시 테이블로 성능 문제를 완화할 수 있다. 예를 들어 테이블을 루프로 순환하면서 계산을 기반으로 열을 변경해야 하는 경우, 업데이트하려는 후보 데이터를 가져와 임시 테이블에 넣고 커서로 이 테이블을 순환한 다음 모든 업데이트를 하나의 작업에서 업데이트할 수 있다. 이 방식으로 커서 처리를 일괄 작업으로 나눌 수도 있다. 
 

스칼라 함수보다는 테이블-값 함수 사용 

스칼라 함수는 계산을 저장 프로시저와 유사한 SQL 조각으로 캡슐화한다. SELECT 쿼리에서 스칼라 함수의 결과를 열로 반환하기 위해 일반적으로 사용하는 방법이다. 마이크로소프트 SQL 서버에서 이 작업을 많이 해 왔다면, 이제는 테이블-값 함수를 사용하고 쿼리에서 CROSS APPLY를 사용해보자. 더 좋은 성능을 얻을 수 있다. 잘 알려지지 않은 APPLY 연산자에 대한 자세한 내용은 마이크로소프트 버추얼 아카데미에서 제공하는 이 자료에서 볼 수 있다.
 

파티셔닝을 사용해 큰 데이터 이동 방지 

SQL 서버 엔터프라이즈는 “파티셔닝” 기능을 제공한다. 이 기능을 사용하면 데이터베이스 테이블을 여러 파티션으로 나눌 수 있다. 한 테이블을 다른 테이블로 지속적으로 아카이빙한다면 INSERT/DELETE를 사용해 데이터를 옮기지 않고 대신 SWITCH를 사용할 수 있다. 예를 들어 매일 내용을 비워서 아카이브 테이블에 넣는 테이블이 있다면 SWITCH를 사용해서 간단히 일일 테이블의 페이지를 아카이브 테이블에 할당하는 방법으로 이 비우고 복사하기 작업을 수행할 수 있다. 스위칭 프로세스에 소요되는 시간은 수동 복사/삭제에 비하면 훨씬 적다. 캐드린 윌렘슨은 이 방식으로 파티셔닝을 사용하는 방법에 대한 좋은 자습서를 제공한다. 
 

성능을 위해서는 저장 프로시저를, 편리함을 위해서는 ORM 사용 

객체 관계 매퍼(ORM)은 SQL 코드를 생성하는 소프트웨어 툴킷으로, 애플리케이션의 프로그래밍 언어와 해당 메타포를 사용해 쿼리를 개발하고 유지하는 데 유용하다. 대다수 데이터베이스 개발자는 원칙적으로 ORM을 좋아하지 않는다. 비효율적이고 최적화할 수 없는 코드를 만드는 것으로 악명이 높고, 개발자 입장에서 SQL을 배우고 쿼리가 무엇을 하는지 이해하고자 하는 동기 부여도 거의 되지 않기 때문이다. 이 툴킷만 사용하면 개발자가 가능한 최선의 성능을 얻기 위해 수동으로 쿼리를 작성해야 하는 경우 어떻게 해야 할지를 모르게 된다.

반대로, ORM을 사용하면 데이터베이스 코드를 훨씬 더 쉽게 쓰고 유지할 수 있다. 애플리케이션에서 데이터베이스 부분은 다른 영역에 따로 떨어진 것이 아니며, 애플리케이션 로직에 느슨하게 결합되는 방식으로 작성된다. 끊임없이 호출되고 우수한 성능이 필요하며 자주 변경될 가능성이 낮고(아예 변경되지 않거나) 데이터베이스의 프로파일링 툴에서 성능을 조사해야 하는 쿼리에는 저장 프로시저를 사용하는 것이 가장 합리적이다. 대부분의 데이터베이스에서는 애드혹 쿼리보다 저장 프로시저를 집계해 이러한 통계를 얻는 편이 더 쉽다. 또한 데이터베이스의 쿼리 플래너에서 저장 프로시저를 최적화하기도 더 쉽다. 

더 많은 데이터베이스 로직을 저장 프로시저로 옮길 때의 단점은 로직이 데이터베이스에 훨씬 더 강하게 결합된다는 것이다. 즉, 성능상의 이점이었던 저장 프로시저가 막대한 기술적 부채로 바뀔 수 있다. 나중에 다른 데이터베이스로 마이그레이션해야 하는 상황이 되면, 모든 저장 프로시저를 다시 쓰는 것보다 ORM 대상을 변경하는 것이 더 쉽다. 또한 최적화를 위해 ORM에서 생성한 코드를 검사할 수 있으며, 쿼리 캐싱은 가장 일반적으로 생성되는 쿼리를 재사용할 수 있게 해준다. 정리하면 앱 측면의 유지관리성이 중요하다면 ORM을 사용하고, 데이터베이스 측면의 성능이 중요하다면 저장 프로시저를 사용하면 된다. 
editor@itworld.co.kr