쿼리 성능 가이드라인

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

이 문서는 SQL 쿼리 최적화 시 따라야 할 다양한 가이드라인을 설명합니다. SQL 쿼리를 최적화할 때는 두 가지 측면에 주의해야 합니다: 쿼리 실행 시간. 이는 사용자가 GitLab을 경험하는 방식을 반영하므로 가장 중요합니다. 쿼리 플랜. 쿼리 플랜을 최적화하는 것은 쿼리가 시간이 지남에 따라 독립적으로 확장될 수 있도록 하는 데 중요합니다. 쿼리가 저하되기 전에 테이블이 커지더라도 인덱스가 쿼리 성능을 유지해 준다는 사실을 사전에 파악하는 것이 이러한 플랜을 분석하는 이유 중 하나입니다. 쿼리 타이밍 가이드라인 # 쿼리 유형 최대 쿼리 시간 비고 일반 쿼리 100ms 엄격한 제한은 아니지만, 쿼리가 이 시간을 초과할 경우 최적화 가능 여부 및 그 이유를 파악하는 데 시간을 투자하는 것이 중요합니다. 마이그레이션 내 쿼리 100ms 이는 전체 마이그레이션 시간과는 다릅니다. 마이그레이션 내 동시 작업 5분 동시 작업은 데이터베이스를 차단하지 않지만 GitLab 업데이트를 차단합니다. add_concurrent_index, add_concurrent_foreign_key, validate constraint(예: add_text_limit을 통한 텍스트 제한 추가) 등의 작업이 포함됩니다. 포스트 마이그레이션 내 동시 작업 20분 동시 작업은 데이터베이스를 차단하지 않지만 GitLab 포스트 업데이트 프로세스를 차단합니다. add_concurrent_index, add_concurrent_foreign_key, validate constraint(예: add_text_limit을 통한 텍스트 제한 추가) 등의 작업이 포함됩니다. 인덱스 생성이 20분을 초과하는 경우 비동기 인덱스 생성을 고려하세요. 백그라운드 마이그레이션 1s Service Ping 1s 자세한 내용은 Metrics Instrumentation 문서를 참조하세요. 쿼리 성능을 분석할 때, 확인 중인 시간이 콜드 또는 웜 캐시 상태에서의 수치인지 주의하세요. 이 가이드라인은 두 캐시 유형 모두에 적용됩니다. 배치 쿼리를 작업할 때는 범위 및 배치 크기를 변경하여 쿼리 타이밍과 캐싱에 어떤 영향을 미치는지 확인하세요. 기존 쿼리의 성능이 좋지 않은 경우, 개선하려는 노력을 기울이세요. 너무 복잡하거나 개발이 지연될 경우, 적시에 처리할 수 있도록 후속 작업을 생성하세요. 데이터베이스 리뷰어 또는 메인테이너에게 도움과 지도를 요청할 수 있습니다. 콜드 및 웜 캐시 # 쿼리 성능을 평가할 때는 콜드 캐시와 웜 캐시 쿼리의 차이를 이해하는 것이 중요합니다. 쿼리가 처음 실행될 때는 "콜드 캐시" 상태로 실행됩니다. 즉, 디스크에서 읽어야 한다는 뜻입니다. 쿼리를 다시 실행하면 데이터를 캐시, 즉 PostgreSQL이 공유 버퍼(shared buffers)라고 부르는 곳에서 읽을 수 있습니다. 이것이 "웜 캐시" 쿼리입니다. EXPLAIN 플랜 을 분석할 때, EXPLAIN(analyze, buffers) 로 실행하여 Buffers 출력을 확인함으로써 타이밍뿐만 아니라 차이를 확