쿼리 성능 가이드라인

SQL 쿼리 최적화 시 따라야 할 다양한 가이드라인과 콜드/웜 캐시, 느린 목록 뷰 처리 방법을 설명합니다.

이 문서는 SQL 쿼리를 최적화할 때 따라야 할 여러 가이드라인을 설명합니다. SQL 쿼리를 최적화할 때는 두 가지 축에 주의합니다. 쿼리 실행 시간. 사용자가 GitLab을 어떻게 체감하는지를 그대로 반영하므로 가장 중요합니다. 쿼리 실행 계획. 실행 계획을 최적화하면 시간이 지나도 쿼리가 독립적으로 확장될 수 있습니다. 테이블이 커져도 인덱스 덕분에 쿼리 성능이 떨어지지 않고 유지된다는 점을 확인하는 것이 실행 계획을 분석하는 이유 중 하나입니다. 플래너가 IN (...) 술어를 잘못 추정해 인덱스 스캔 대신 순차 스캔을 선택하는 경우에는 값마다 인덱스 탐색을 한 번씩 강제하는 재작성 방법을 LATERAL 조인으로 인덱스 탐색 강제하기 에서 확인합니다. 쿼리 시간 가이드라인 # 쿼리 유형 최대 쿼리 시간 비고 일반 쿼리 100ms 엄격한 상한은 아니지만, 쿼리가 이 시간을 넘기기 시작하면 최적화가 가능한지 또는 불가능한지를 시간을 들여 파악하는 일이 중요합니다. 마이그레이션 내 쿼리 100ms 전체 마이그레이션 시간 과는 다른 기준입니다. 마이그레이션 내 동시 작업 5min 동시 작업은 데이터베이스를 차단하지는 않지만 GitLab 업데이트를 차단합니다. add_concurrent_index , add_concurrent_foreign_key , 제약 조건 검증(예를 들어 add_text_limit 로 텍스트 길이 제한 추가) 같은 작업이 여기에 해당합니다. 포스트 마이그레이션 내 동시 작업 20min 동시 작업은 데이터베이스를 차단하지는 않지만 GitLab 포스트 업데이트 과정을 차단합니다. add_concurrent_index , add_concurrent_foreign_key , 제약 조건 검증(예를 들어 add_text_limit 로 텍스트 길이 제한 추가) 같은 작업이 여기에 해당합니다. 인덱스 생성이 20분을 넘긴다면 비동기 인덱스 생성 을 검토합니다. 백그라운드 마이그레이션 1s Service Ping 1s 자세한 내용은 메트릭 계측 문서 를 참고합니다. 쿼리 성능을 분석할 때는 측정된 시간이 콜드 캐시인지 웜 캐시인지 를 확인합니다. 이 가이드라인은 두 캐시 유형 모두에 적용됩니다. 배치 쿼리를 다룰 때는 범위와 배치 크기를 바꿔 가며 쿼리 시간과 캐싱에 어떤 영향을 주는지 확인합니다. 기존 쿼리의 성능이 좋지 않다면 개선을 시도합니다. 너무 복잡하거나 개발을 지연시킬 정도라면 후속 작업을 만들어 제때 처리할 수 있도록 합니다. 언제든 데이터베이스 리뷰어나 메인테이너에게 도움과 조언을 요청할 수 있습니다. 콜드 캐시와 웜 캐시 # 쿼리 성능을 평가할 때는 콜드 캐시 쿼리와 웜 캐시 쿼리의 차이를 이해하는 일이 중요합니다. 쿼리를 처음 실행하면 "콜드 캐시" 상태에서 실행됩니다. 즉 디스크에서 읽어야 합니다. 같은 쿼리를 다시 실행하면 데이터를 캐시, 즉 PostgreSQL 이 공유 버퍼라고 부르는 영역에서 읽을 수 있습니다. 이것이 "웜 캐시" 쿼리입니다. EXPLAIN 실행 계획 을 분석할 때는 시간뿐 아니라 EXPLA