MySQL 기반 운영 대시보드에서 오류 로그의 목록 조회와 건수 계산에 각각 약 22초가 걸렸다. 특정 플러그인과 사용자, 시간 구간을 고른 뒤 대부분을 차지하는 [INFO] 로그를 제외하는 화면이었다. 로그 테이블에는 기본 키만 있어 조회할 때마다 전체를 훑었다.
조회 조건을 살펴보면 인덱스 하나로 끝낼 수 있는 문제가 아니었다. 상세 화면은 플러그인·사용자·시간을 함께 걸렀고 목록은 [INFO]로 시작하지 않는 행을 세면서 최신순으로 정렬했다. 단일 열 인덱스를 여러 개 붙여도 이런 조건의 조합을 그대로 지원하지는 못한다.
그래서 실제 조회 형태에 맞춰 시간 단일 인덱스와 플러그인·시간, 플러그인·사용자·시간 복합 인덱스를 추가했다. 로그 요약에는 16자 접두 인덱스를 붙였다. 이후 상세 조회는 21.916초에서 0.039밀리초로, 목록은 22.105초에서 3.630밀리초로, 건수 계산은 21.920초에서 2.970밀리초로 줄었다.
부정 접두 조건인 “[INFO]로 시작하지 않음”은 인덱스 범위를 직접 쓰기 어려웠다. 이 데이터베이스의 이진 정렬 조건을 이용해 error_summary < '[INFO]' 또는 error_summary >= '[INFO^'라는 두 범위로 바꿨다. 기존 조건과 새 조건이 모두 353건을 반환하는지 확인한 뒤 속도 개선을 받아들였다.
다른 대시보드의 상태·시간 집계 조회는 약 11,081행을 반환하면서 1.077초가 걸렸고 옵티마이저는 여전히 전체 스캔을 선택했다. 모든 느린 조회를 인덱스 부족으로만 설명해서는 안 되는 사례다. 많은 결과를 읽고 집계해야 한다면 인덱스를 더 붙이기 전에 조회 형태와 반환 범위를 살펴봐야 한다.
이번 수치는 한 로그 분포와 이진 정렬 조건에서 얻었으므로 다른 데이터베이스에 그대로 적용할 수 없다. 느린 조회를 고칠 때는 “어느 열에 인덱스가 없는가”보다 “실제 조건·정렬·집계가 어떤 범위를 읽는가”를 먼저 확인해야 한다. 특히 부정 조건을 범위로 바꾼 경우에는 성능 수치뿐 아니라 결과 건수도 같은지 검증해야 한다.