Update README.md

[munhyerin22]

수정 했습니다

[github-actions]

🤖 AI 코드리뷰

리더보드 — 현재 4위 (리뷰 110건) | 전체 8개 팀 참여 중
업데이트 확인 — 리뷰가 질문을 던지다 — 생각해보기

📋 과제 요구사항 준수 여부

• 인덱스 최적화 (도전): EXPLAIN 분석 결과(Before/After)를 명확하게 인증했습니다. type=ALL, key=NULL에서 ref/range로 개선된 점, 그리고 스캔 행 수(49680 → 18170)를 수치로 제시한 부분은 요구사항에 부합합니다.

🟡 개선 제안

1. EXPLAIN 결과 스크린샷에 대한 명확한 설명 누락
diff를 보면 적용했지만 실패라는 이미지 파일명과 최적의 쿼리라는 이미지 파일명이 추가되었습니다. "실패"와 "best"가 어떤 쿼리 플랜의 차이인지 텍스트로 설명이 없습니다.
인덱스 설계가 실패한 원인(예: 카디널리티 문제, 복합 인덱스 컬럼 순서 등)과 이를 해결하여 "best"가 된 과정을 서술해야 합니다. 운영 환경에서는 스크린샷만으로 장애 상황을 공유할 수 없습니다. 원인과 해결 과정이 문서화되어야 합니다.

2. 관련 테이블 인덱스 스키마 삭제
orders, order_products, search_keywords, chat_messages 테이블의 인덱스 생성 SQL이 삭제되었습니다. 이 문서가 프로젝트의 단일 진실 공급원(SSOT) 역할을 해야 한다면, 다른 도메인에 적용된 인덱스 전략까지 지워버리는 것은 향후 운영 및 온보딩에 악영향을 미칩니다. 의도적인 정리라면 이유를 남기는 것이 좋습니다.

💡 학습 포인트

• EXPLAIN과 rows: rows 컬럼은 MySQL 옵티마이저가 통계 정보를 바탕으로 '예상'하는 스캔 행 수입니다. 실제 I/O와 다를 수 있으므로, 실행 시간(Execution Time)과 함께 종합적으로 판단해야 합니다.

🤔 생각해보기

diff에 남긴 "적용했지만 실패" 쿼리 플랜은 정확히 어떤 문제(예: 인덱스를 타지 못함, 잘못된 컬럼 순서 등)를 가지고 있었으며, "최적의 쿼리"는 어떤 방식으로 옵티마이저가 이를 해결했나요? 인덱스를 생성했다고 무조건 옵티마이저가 그것을 타는 것은 아닙니다.

💬 이 질문에 대해 궁금한 점이 있으면 코멘트에 @sparta 를 남겨보세요!
예: @sparta 옵티마이저가 인덱스를 무시하고 Full Table Scan을 선택하는 기준은 무엇인가요?

---

AI 리뷰는 참고용입니다. 최종 판단은 팀원이 직접 합니다.