실험 목적

판교역 기준 1·5·10·30km 주변 응급실을 찾는 두 쿼리를 비교했다. 두 경로 모두 거리를 계산하고 거리순으로 정렬한다. 정렬 없는 버퍼 쿼리의 이전 성능 수치는 이 비교에 포함하지 않았다.

A — MBR + 거리: SPATIAL 인덱스의 MBR 후보 검색 → ST_Distance_Sphere 구면 거리 계산 → 지정 반경 필터 → 거리순 정렬.

B — 버퍼 + 정렬: ST_Buffer 도형에 ST_Within 포함 판정 → ST_Distance_Sphere 거리 계산 → 거리순 정렬.

측정 조건

• 측정일: 2026-10-01, AWS 서울 리전. 중심: 판교역 (127.1112, 37.3948). 서비스 화면에서 제공하는 최대 검색 반경은 30km다. 이 페이지의 1km 원본 측정치는 보존하되 블로그 비교 표에서는 제외했다.
• 각 반경에서 A–B–B–A 순서. 각 케이스 25 VU × 60초 워밍업 후 100 VU × 180초 본 측정, 30초 간격.
• 백엔드 EC2 t4g.small, RDS MySQL 8.4.9 / db.t4g.micro, 부하 발생 EC2 c7i-flex.large / k6 2.2.0.
• 응급실 530행 중 활성 528행(2026-09-29 확인); Hikari 최대 10개. coordinate POINT SRID 4326 NOT NULL, SPATIAL INDEX idx_emergency_coordinate (coordinate).
• 중심점 POINT(?, ?)의 JDBC 바인딩은 경도→위도. CSV 좌표와 경계 폴리곤 WKT에는 axis-order=long-lat 지정. MySQL SRID 4326의 기본 축 순서는 위도→경도지만, ST_SRID()는 이미 생성한 점의 좌표를 변환하지 않고 SRID만 바꾼다. MySQL 축 순서 · ST_SRID.
• 100 VU는 실제 동시 이용자 추정치가 아니라 초기 인프라에 충분한 동시 요청을 발생시키기 위한 부하 기준이다.

거리식 표기 변경: 별도 선행 측정

초기 SQL은 거리식을 SELECT와 WHERE에 각각 적었다. SQL 표기만으로 실제 함수 평가 횟수를 확정할 수는 없다.

SELECT id, name,
       ST_Distance_Sphere(coordinate, ST_SRID(POINT(?, ?), 4326)) AS distance_meters
FROM emergency FORCE INDEX (idx_emergency_coordinate)
WHERE active = TRUE
  AND MBRContains(ST_GeomFromText(?, 4326, 'axis-order=long-lat'), coordinate)
  AND ST_Distance_Sphere(coordinate, ST_SRID(POINT(?, ?), 4326)) <= ?
ORDER BY distance_meters;

변경 후에는 SELECT의 거리 별칭을 HAVING에서 사용했다. 이 별칭 사용법은 MySQL 문법에 의존한다.

SELECT id, name,
       ST_Distance_Sphere(coordinate, ST_SRID(POINT(?, ?), 4326)) AS distance_meters
FROM emergency FORCE INDEX (idx_emergency_coordinate)
WHERE active = TRUE
  AND MBRContains(ST_GeomFromText(?, 4326, 'axis-order=long-lat'), coordinate)
HAVING distance_meters <= ?
ORDER BY distance_meters;

두 경로 모두 거리순 정렬을 수행했다. 아래 값은 2회 평균이며, 변경 후 처리량과 p95가 개선됐다. 측정 시점이 달라 표현식 평가 횟수만의 효과로 단정하지 않는다.

HTTP 반복별 결과

RPS는 초당 요청 수, p95는 95백분위 응답 시간(ms). 모든 케이스 실패율 0%.