=== 성능 개선 효과 (운영 DB, 2026-09-15) ===
측정 기준: params.sql (MaestroID 181, AppID 21, @day 2026-08-26, @hour 9)
측정 시점: 베이스라인 22:5x (인덱스 추가 전) / 개선 후 23:1x (인덱스 7개 추가 후)

| 쿼리               | access_type (전→후)   | rows (전→후)          | 서버 시간 ms (전→후, ANALYZE) | 결과 행 수 |
|--------------------|-----------------------|-----------------------|-------------------------------|-----------|
| q1 시간별 · 함수   | index_merge → ref     | 10,103 → 5,851 (1.7배) | 74.61 → 2.07 (36배)           | 22 = 22   |
| q2 시간별 · 범위   | index_merge → range   | 10,103 → 22 (459배)    | 75.58 → 0.26 (292배)          | 22 = 22   |
| q3 일간 · 함수     | index_merge → ref     | 10,103 → 5,851 (1.7배) | 75.29 → 2.44 (31배)           | 61 = 61   |
| q4 일간 · 범위     | index_merge → range   | 10,103 → 99 (102배)    | 75.24 → 0.47 (161배)          | 61 = 61   |
| q5 월간 · 함수     | index_merge → ref     | 10,103 → 5,851 (1.7배) | 76.27 → 4.30 (18배)           | 262 = 262 |
| q6 월간 · 범위     | index_merge → range   | 10,103 → 709 (14배)    | 79.70 → 2.50 (32배)           | 262 = 262 |

사용 인덱스: 개선 후 6개 모두 idx_maestro_app_dt (MaestroID, AppID, RecordDateTime)
클라이언트 시간 (네트워크 포함, 2회차): 약 88~92ms → 13~18ms

참고 (스테이징): rows 5,804 → 1, cost 8.63 → 0.004
참고 (운영 01 사전 측정): 일간 랭킹 index_merge, rows 10,100

결과 행 수 동일 (4-3): [x] 예  [ ] 아니오

결론:
- 인덱스만의 효과 (q1·q3·q5, 함수형 조건):
  rows 추정은 1.7배만 줄었지만 서버 처리 시간은 18~36배 단축.
  기존에는 MaestroID·AppID 단일 인덱스 두 개의 교집합(index_merge)을 구하느라 느렸고,
  복합 인덱스의 (MaestroID, AppID) 앞부분으로 바로 찾게(ref) 되었기 때문.
  날짜 조건은 여전히 인덱스로 거르지 못해 해당 선생님·앱의 기록 약 5,851행을 확인함.
- 인덱스 + 쿼리 수정 효과 (q2·q4·q6, 범위 조건):
  날짜까지 인덱스로 걸러(range) 조회 기간의 실제 기록만 읽음.
  서버 처리 시간 32~292배 단축, 검사 행 수 14~459배 감소.
  같은 조건에서 함수형 대비 추가로 1.7~9배 빠름 (q1→q2 8배, q3→q4 5배, q5→q6 1.7배).

중복 정리 (03-0):
- app_highest_record 8,795행 삭제 (4,823조합), 220,648행 = 220,648조합
- UNIQUE 키 2개 추가 완료 → 이후 중복 저장은 DB가 거부

Slow query log (04-5, 23:08 이후 1시간):
- 0.5초 이상은 작업 SQL 5건(ALTER 4건, 중복 DELETE 1건)뿐, 애플리케이션 쿼리 0건
- 새벽이 아닌 밤 시간이고 기간이 짧으므로 24시간 뒤 다시 확인 필요 (07단계)