Files
jisangs 03eea2098e 운영 서버에서 DB index 적용 작업 진행
- 01~07 작업 문서를 운영 측정값 기준으로 정리 (문서의 DB 비밀번호 삭제)
- app_highest_record 중복 8,795행 점수 기준 정리, 인덱스 5개 + UNIQUE 키 2개 추가
- 02·04 공통 측정 스크립트와 측정 결과, comparison.txt 추가
- 서버 처리 시간 18~292배 단축, 결과 행 수 동일
- 운영 데이터 백업과 권한(비밀번호 해시) 파일은 커밋에서 제외

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 23:30:42 +09:00

4.3 KiB

05단계: 최종 체크리스트

운영 서버 인덱스 적용 전후 모든 단계를 최종 확인합니다.


준비 단계

  • DB 백업 (전체 mariadb-dumpbackup_chocomae_full_20260915.sql.gz, 로컬 복원 테스트 통과)
  • 운영 DB 현황 측정 (01-premeasure.md, 2026-09-15)
  • 계정 권한 확인 (01 1-0: SELECT, ALTER만 있음)
  • 작업 권한 임시 부여 (SUPER, 최고기록 테이블 2개 INSERT·DELETE, mysql.slow_log SELECT — premeasure_grants_after.txt)
  • Slow query log 원래 설정 저장 (01 1-4: ON, long_query_time=3, log_output=FILE)
  • app_highest_record 전체 중복 개수 확인 (01 1-5-2: 4,823조합, 삭제 대상 8,795행)

베이스라인 측정 (02-baseline.md)

  • 지난달 측정 기준 시각 선정, params.sql 작성
  • Slow query log 켜기 (jisangs 계정, log_queries_not_using_indexes는 켜지 않음)
  • queries/ 6개, run_measure.sh, summarize_explain.py 작성
  • zsh run_measure.sh baseline 실행
    • baseline_explain_q*.json 6개
    • baseline_perf.txt
  • 확인: 함수형·범위형 짝(q1↔q2, q3↔q4, q5↔q6)의 결과 행 수가 같음
  • 기준값 기록: baseline_explain_summary.txt (운영은 ALL이 아니라 index_merge일 수 있음)

중복 정리·인덱스 추가 (03-add-indexes.md)

  • 3-0-1 중복 규모 확인 (rows_to_delete 메모)
  • 3-0-2 삭제 대상 행 백업 backup_app_highest_dup_rows.sql (백업 행 수 = rows_to_delete)
  • 3-0-3 중복 삭제 (rows affected = rows_to_delete)
  • 확인: 두 테이블 모두 total_rows = unique_combos
  • add_indexes.sql 준비
  • 인덱스 추가 실행 (add_indexes_result.txt, ALTER 7개 모두 Query OK)
  • SHOW PROCESSLIST로 진행 상황 모니터링 생략 (ALTER 7개 합계 약 12초)
  • 새 인덱스 7개 확인 (add_indexes_check.txt)

개선 효과 검증 (04-verify.md)

  • zsh run_measure.sh after 실행
  • 확인: 범위형 쿼리(q2, q4, q6)에서 access_type = range, 새 인덱스 사용
  • 확인: rows가 베이스라인보다 크게 감소
  • 확인: 결과 행 수가 베이스라인과 같음 (4-3)
  • 실행 시간 비교, comparison.txt 작성
  • Slow query log에서 느린 쿼리 확인 (after_slow_log.txt)

성공 기준

모두 체크되면 운영 서버 적용 완료:

  • 인덱스 7개 추가 성공
  • 범위형 쿼리가 새 인덱스를 사용 (access_type = range)
  • 쿼리 실행 시간 개선 확인
  • 스캔 행 수 대폭 감소
  • 결과 행 수 변화 없음
  • 서비스 정상 운영 (게임 결과 저장, 최고기록·랭킹·기록 화면) — 2026-09-15 운영에서 확인: 게임 결과 저장·최고기록, 시간·일·월 랭킹, 최근 7번 기록 화면, 타자 시험 순위와 기록

사후 작업

  • Slow query log 설정을 원래 값으로 복원 (jisangs 계정 — SUPER 회수 전에 실행, 2026-09-15 완료: ON / 3 / FILE / OFF)

    -- 01 1-4에서 저장한 원래 값 (premeasure_slow_log_settings.txt)
    SET GLOBAL slow_query_log = 'ON';
    SET GLOBAL long_query_time = 3;
    SET GLOBAL log_output = 'FILE';
    
  • 임시로 부여한 권한 회수 (관리자 계정, slow log 복원 후) — 2026-09-15 완료, result/grants_after_revoke.txt: USAGE + SELECT, ALTER ON chocomae.*만 남음

    REVOKE DELETE, INSERT ON chocomae.app_highest_record FROM 'jisangs'@'182.217.174.221';
    REVOKE DELETE, INSERT ON chocomae.typing_exam_highest_record FROM 'jisangs'@'182.217.174.221';
    REVOKE SELECT ON mysql.slow_log FROM 'jisangs'@'182.217.174.221';
    REVOKE SUPER ON *.* FROM 'jisangs'@'182.217.174.221';
    
    -- 기대 결과: GRANT USAGE ... 와 GRANT SELECT, ALTER ON `chocomae`.* 두 줄만 남음
    SHOW GRANTS FOR 'jisangs'@'182.217.174.221';
    
  • 임시 계정 jisangs@182.217.174.221 삭제 (2026-09-15, root 계정으로 DROP USER)

  • [ ] 같은 비밀번호를 쓰는 다른 계정 교체 (Gmail SMTP, Python 배치의 DB root 설정) — 취소 (2026-09-15)

  • [ ] 팀원 통보 (작업 완료) — 취소 (2026-09-15)

  • 모니터링 (24시간)

  • 문제 발생 시 롤백 준비 완료 (06-rollback.md)

  • 사후 분석 (07-post-analysis.md)


운영 서버 적용 완료!