docs: explain-matrix의 지도 블록을 keyword 검색 추가 이후 코드와 맞춘다

[minyongP]

요약

dev #180(S15P11A705-301)이 지도 마커 API에 keyword 검색을 더한 뒤, explain-matrix.sql이 그 이전 쿼리를 담고 있어 실제 코드와 다른 쿼리를 재고 있었다. [3] 블록을 현재 코드와 동기화하고 세 갈래로 나눈다.

Jira (필수)

• 없음 — 문서·측정 SQL 전용 변경

변경 사항

• loadtest/sql/explain-matrix.sql — [3] 블록을 세 갈래로 분리
  • [3a] bbox 없음 · keyword 없음 → findMarkers (부하 시나리오가 부르는 쪽)
  • [3b] bbox 있음(서울) · keyword 없음 → 프론트 지도 화면 기본 경로
  • [3c] bbox 있음(서울) · keyword 있음 → 지도 검색 경로
  • keyword 조건은 세 쿼리 WHERE에 항상 들어간다(null일 때도 단락 평가가 계획에 남음). 패턴은 RecordService.toLikeKeyword가 만드는 형태(%…% · 소문자화 · ! 이스케이프)를 리터럴로 적었다
  • ORDER BY가 없는 것이 정상임을 주석에 남겼다 — 이름 정렬은 collation 의존성 회피를 위해 자바에서 한다(RecordService.sortByName)
• docs/backend/implements/BI-38-… — 보존 구역이라 본문 수치는 그대로 두고 「이후 코드 변경 (추가 기록)」 절을 덧붙였다. 개선 후보 3의 성격도 실측 결과에 맞게 좁혔다

테스트 / 검증

• 자바·설정 변경 없음 (git diff --name-only → .md·.sql만) — clean check 대상 코드 무변경

갱신된 매트릭스를 천만 건 볼륨에 실제로 돌려 문법과 계획을 확인했다 (종료 코드 0, member 2792 · 후보 697행):

갈래	계획	반환	시간
[3a] bbox 없음 · keyword 없음	Nested Loop + place_pkey	697행	12.16 ms
[3b] bbox 있음 · keyword 없음	Nested Loop + place_pkey	397행	1.21 ms
[3c] bbox 있음 · keyword 있음	Nested Loop + place_pkey	7행	1.56 ms

접근 경로가 세 갈래 모두 동일하다. 회원 record를 uq_record_active로 먼저 좁힌 뒤 place를 PK로 확인하며 bbox·LIKE를 필터로 적용한다. 양끝 와일드카드 LIKE가 인덱스를 쓰지 못하는 것은 사실이지만 697회 루프 안에서만 평가되므로 규모 문제가 되지 않는다 — BI-38 판정 4의 결론(표 크기에 비례하지 않고 회원 데이터에만 비례)은 변경 후에도 유지된다.

([3b]·[3c]는 [3a]의 워밍 이득을 받은 같은 실행 안의 값이라 갈래 간 절대값 비교에는 쓰지 않았다. 계획 모양 확인이 목적이다.)

리뷰 포인트

1. BI-38이 보존 구역이라 본문을 고치지 않고 절을 덧붙인 처리 — docs/backend/README.md 규약에 맞는지
2. keyword 리터럴을 NULL IS NULL 형태로 적어 null 경로를 재현한 방식 — 실제 바인딩과 계획이 같은지

🤖 Generated with Claude Code