이 페이지는 데이터베이스 리뷰에 특화된 내용을 다룹니다. 코드 리뷰 전반에 대한 더 넓은 조언과 모범 사례는 코드 리뷰 가이드를 참조하세요.

일반 프로세스#

다음에 해당하는 경우 데이터베이스 리뷰가 필요합니다:

• 데이터베이스 스키마를 건드리거나 데이터 마이그레이션을 수행하는 변경 사항. 다음 파일들이 포함됩니다:

db/

• lib/gitlab/background_migration/

• 데이터베이스 도구에 대한 변경 사항. 예를 들면:

lib/gitlab/database/의 마이그레이션 또는 ActiveRecord 헬퍼

• 로드 밸런싱

• 명확하지 않은 SQL 쿼리를 생성하는 변경 사항. 복잡한 쿼리가 도입되었는지 여부와 데이터베이스 리뷰가 필요한지 여부를 결정하는 것은 일반적으로 머지 리퀘스트 작성자의 판단에 달려 있습니다.

• count, distinct_count, estimate_batch_distinct_count, sum을 사용하는 Service Data 메트릭의 변경 사항. 이러한 메트릭은 대규모 테이블에 대해 복잡한 쿼리를 실행할 수 있습니다. 구현 세부 정보는 Analytics Instrumentation Guide를 참조하세요.

• ActiveRecord 객체에서 update, upsert, delete, update_all, upsert_all, delete_all 또는 destroy_all 메서드를 사용하는 변경 사항.

데이터베이스 리뷰어는 변경 사항에서 지나치게 복잡한 쿼리를 찾아 더 면밀히 검토해야 합니다. 작성자가 특정 쿼리를 리뷰 대상으로 지목하지 않았고 지나치게 복잡한 쿼리도 없다면, 마이그레이션 리뷰에만 집중해도 충분합니다.

필수 항목#

~database 리뷰를 요청할 때 다음 아티팩트를 제공해야 합니다. 머지 리퀘스트 설명에 이 항목들이 포함되지 않은 경우, 리뷰는 작성자에게 재할당됩니다.

마이그레이션#

새 마이그레이션이 도입된 경우, 데이터베이스 리뷰어는 모든 마이그레이션에 대해 마이그레이션 적용(db:migrate)과 롤백(db:rollback) 양쪽의 출력 결과를 검토해야 합니다.

GitLab을 위한 자동화 도구가 있으며 (db:check-migrations 파이프라인 job으로 제공), 해당 도구가 CI job 로그에 이 출력을 제공합니다. 작성자가 머지 리퀘스트 설명에 이 출력을 제공할 필요는 없지만, 리뷰어에게 도움이 될 수 있습니다. 봇은 또한 마이그레이션이 올바르게 되돌릴 수 있는지도 확인합니다.

쿼리#

새 쿼리가 도입되었거나 기존 쿼리가 업데이트된 경우, 다음을 제공해야 합니다:

• 머지 리퀘스트에 포함된 각 원시 SQL 쿼리에 대한 쿼리 플랜과 각 원시 SQL 스니펫 다음에 쿼리 플랜 링크.

• 변경되거나 추가된 모든 쿼리의 원시 SQL(ActiveRecord 쿼리에서 변환된 것).

기존 쿼리를 업데이트하는 경우, 이전 버전과 새 버전 쿼리의 원시 SQL을 해당 쿼리 플랜과 함께 제공해야 합니다.

이 정보를 제공하는 방법은 쿼리 추가 또는 수정 시 준비 사항을 참조하세요.

역할 및 프로세스#

머지 리퀘스트 작성자의 역할:

• 데이터베이스 리뷰가 필요한지 결정합니다.

• 데이터베이스 리뷰가 필요한 경우 ~database 라벨을 추가합니다.

• 데이터베이스 리뷰를 위해 머지 리퀘스트를 준비합니다.

• MR 제출 전에 필수 아티팩트를 제공합니다.

데이터베이스 리뷰어의 역할:

• 필수 아티팩트가 올바른 형식으로 제공되었는지 확인합니다. 그렇지 않은 경우 머지 리퀘스트를 작성자에게 재할당합니다.

• MR에 대한 1차 리뷰를 수행하고 작성자에게 개선 사항을 제안합니다.

• 만족스러우면 MR에 ~"database::reviewed" 라벨을 다시 붙이고 승인한 다음, Reviewer Roulette가 제안한 데이터베이스 메인테이너에게 리뷰를 요청합니다.

데이터베이스 메인테이너의 역할:

• MR에 대한 최종 데이터베이스 리뷰를 수행합니다.

• 데이터베이스 리뷰어 및 MR 작성자와 추가 개선 사항 또는 기타 관련 변경 사항을 논의합니다.

• 최종적으로 MR을 승인하고 MR에 ~"database::approved" 라벨을 붙입니다.

• 다른 승인이 남아 있지 않으면 MR을 머지하거나, 필요에 따라 다른 메인테이너(프론트엔드, 백엔드, 문서)에게 전달합니다.

리뷰 작업 분배#

리뷰 작업은 리뷰어 룰렛을 사용하여 배분됩니다 (예시). MR 작성자는 제안된 데이터베이스 리뷰어에게 리뷰를 요청해야 합니다. 리뷰어가 승인하면 제안된 데이터베이스 메인테이너에게 인계됩니다.

리뷰어 룰렛이 데이터베이스 리뷰어 및 메인테이너를 제안하지 않은 경우, ~database 라벨이 적용되어 있는지 확인하고 danger-review CI job을 다시 실행하거나, @gl-database 팀에서 직접 선택하세요.

데이터베이스 리뷰를 위한 머지 리퀘스트 준비 방법#

리뷰를 더 쉽고 빠르게 만들려면 다음 준비 사항을 고려하세요.

마이그레이션 추가 시 준비 사항#

• db/structure.sql이 문서화된 대로 업데이트되었는지 확인하고, 추가로 db/schema_migrations 하위의 관련 버전 파일이 추가 또는 제거되었는지 확인합니다.

• Database Dictionary가 문서화된 대로 업데이트되었는지 확인합니다.

• change 메서드를 사용하거나, up을 사용할 때 down 메서드를 포함하여 마이그레이션을 되돌릴 수 있게 만듭니다.

롤백 절차를 포함하거나 변경 사항을 롤백하는 방법을 설명합니다.

• db:check-migrations 파이프라인 job이 성공적으로 실행되었으며 마이그레이션 롤백이 예상대로 작동하는지 확인합니다.

db:check-schema job이 성공적으로 실행되었으며 롤백 시 예상치 못한 스키마 변경이 도입되지 않는지 확인합니다. 스키마가 변경된 경우 이 job은 경고만 발생시킬 수 있습니다.

• 리뷰 과정에서 마이그레이션을 수정할 때마다 앞서 언급한 job들이 계속 성공하는지 확인합니다.

• 필요한 경우 spec/migrations에 마이그레이션 테스트를 추가합니다. 자세한 내용은 GitLab에서 Rails 마이그레이션 테스트하기를 참조하세요.

• 잠금 재시도는 모든 트랜잭션 마이그레이션에 기본적으로 활성화되어 있습니다. 비트랜잭션 마이그레이션의 경우, 사용 사례와 해결 방법에 대한 관련 문서를 검토하세요.

• 유효한 이유가 없는 한 RuboCop 검사를 비활성화하지 않도록 합니다.

• 대규모 테이블에 인덱스를 추가할 때, Database Lab에서 CREATE INDEX CONCURRENTLY를 사용하여 실행을 테스트하고 실행 시간을 MR 설명에 추가합니다:

Database Lab과 GitLab.com 사이의 실행 시간은 크게 다를 수 있지만, Database Lab에서의 실행 시간이 길다면 GitLab.com에서도 실행 시간이 상당히 길다는 힌트가 될 수 있습니다.

• Database Lab에서의 실행 시간이 10분을 초과하는 경우, 인덱스를 포스트 마이그레이션으로 이동해야 합니다. 이 경우 해당 인덱스가 필요한 코드가 배포될 때 인덱스가 준비되어 있도록 마이그레이션과 애플리케이션 변경 사항을 별도의 릴리즈로 분리해야 할 수도 있습니다.

• test Stage에서 데이터베이스 테스트 job(db:gitlabcom-database-testing)을 수동으로 트리거합니다.

이 job은 Database Lab 클론에서 마이그레이션을 실행하고 MR에 결과(쿼리, 런타임, 크기 변경)를 게시합니다.

• 마이그레이션 런타임과 경고를 검토합니다.

데이터 마이그레이션 추가 시 준비 사항#

데이터 마이그레이션은 본질적으로 위험합니다. 프로덕션 데이터의 손상 또는 손실로 이어질 수 있는 오류 가능성을 줄이기 위해 추가적인 조치가 필요합니다.

MR 설명에 다음을 포함하세요:

• 마이그레이션 자체를 되돌릴 수 없는 경우, 인시던트 발생 시 데이터 변경 사항을 되돌리는 방법에 대한 세부 정보. 예를 들어, 레코드를 삭제하는 마이그레이션의 경우(대부분 자동으로 되돌릴 수 없는 작업), 삭제된 레코드를 복구할 수 있는 방법.

• 마이그레이션이 데이터를 삭제하는 경우 ~data-deletion 라벨을 적용합니다.

• 오류 발생 시 사용자 경험에 미치는 영향에 대한 간결한 설명. 예를 들어, "이슈가 에픽에서 예기치 않게 사라질 수 있습니다".

• 쿼리가 예상대로 작동함을 나타내는 쿼리 플랜의 관련 데이터. 예를 들어 수정 또는 삭제되는 레코드의 대략적인 수.

쿼리 추가 또는 수정 시 준비 사항#

원시 SQL#

MR 설명에 원시 SQL을 작성합니다. pgFormatter나 https://paste.depesz.com으로 보기 좋게 형식을 맞추고, 일반 따옴표(예: "projects"."id")를 사용하며 스마트 따옴표(예: "projects"."id")는 피합니다.

매개변수를 사용하여 동적으로 생성된 쿼리의 경우, 각 변형에 대한 원시 SQL 쿼리가 하나씩 있어야 합니다.

예를 들어, 프로젝트에 대한 선택적 필터를 매개변수로 받을 수 있는 이슈 파인더는 이슈에 대한 쿼리 버전과 이슈 및 프로젝트를 조인하고 필터를 적용하는 버전 모두를 포함해야 합니다.

매우 많은 수의 순열을 생성할 수 있는 파인더나 다른 메서드가 있습니다. 가능한 모든 생성된 쿼리를 빠짐없이 추가할 필요는 없으며, 모든 매개변수가 포함된 쿼리 하나와 생성된 각 쿼리 유형에 대한 쿼리 하나만 있으면 됩니다.

예를 들어, 조인이나 GROUP BY 절이 선택 사항인 경우, GROUP BY 절이 없고 조인이 적은 버전도 포함해야 하며, 나머지 테이블에 대한 적절한 필터는 유지해야 합니다.

쿼리가 항상 limit과 offset을 함께 사용하는 경우, 최대 허용 limit과 0이 아닌 offset을 항상 포함해야 합니다.

애플리케이션에서 실행되는 SQL을 찾는 팁 쿼리를 검토할 때, 스코프, 페이지네이션, limit을 포함하여 실제로 데이터베이스에서 실행되는 SQL 쿼리를 평가하고자 합니다. Rails 코드를 읽어 정확한 쿼리를 추론하는 것은 어렵거나 때로는 불가능할 수 있습니다. 가장 정확한 SQL을 얻으려면 다음 방법 중 하나를 사용해 보세요:

성능 바 사용: 기능을 수동으로 테스트한 다음 성능 바의 pg 섹션을 클릭하여 실행된 SQL 쿼리를 확인합니다. API 요청에 대한 쿼리를 보려면 오른쪽 드롭다운 메뉴에서 요청을 찾아 선택합니다.

development.log 확인: 기능을 테스트한 다음 GitLab 디렉터리의 log/development.log를 확인하여 애플리케이션이 실행한 모든 쿼리를 봅니다. Sidekiq 워커에서 실행된 쿼리는 포함되지 않습니다.

ActiveRecord::Base.logger로 스펙 실행: RSpec 테스트에 다음 블록을 추가하여 쿼리를 표준 출력에 로깅할 수 있습니다:

before do
  ActiveRecord::Base.logger = Logger.new($stdout)
end

after do
  ActiveRecord::Base.logger = nil
end

bundle exec rspec <test_file>로 테스트를 실행하면 쿼리가 테스트 출력에 나타납니다. 이는 통합 테스트에서만 올바른 쿼리를 생성합니다. 페이지네이션 미들웨어와 같이 ActiveRecord 관계를 수정하는 추가 컴포넌트가 있는 경우, 단위 테스트의 출력이 정확하지 않을 수 있습니다.

쿼리 플랜#

• 머지 리퀘스트에 포함된 각 원시 SQL 쿼리에 대한 쿼리 플랜과 각 원시 SQL 스니펫 다음에 쿼리 플랜 링크를 제공합니다.

• postgres.ai 챗봇의 explain 명령을 사용하여 생성된 플랜 링크를 제공합니다. explain 명령은 EXPLAIN ANALYZE를 실행합니다.

Database Lab에서 정확한 결과를 얻을 수 없는 경우, 개발 환경에 데이터를 시드하고 대신 EXPLAIN ANALYZE 출력을 제공해야 할 수 있습니다. explain.depesz.com이나 explain.dalibo.com을 사용하여 플랜 링크를 만듭니다. 폼에 플랜과 사용된 쿼리 모두를 붙여 넣으세요.

• 쿼리 플랜을 제공할 때, 충분한 데이터를 대상으로 실행되는지 확인합니다:

충분한 데이터로 쿼리 플랜을 생성하려면 다음 ID를 사용할 수 있습니다:

그룹이 포함된 쿼리의 경우 gitlab-org 네임스페이스(namespace_id = 9970).

• 프로젝트가 포함된 쿼리의 경우 gitlab-org/gitlab-foss(project_id = 13083) 또는 gitlab-org/gitlab(project_id = 278964) 프로젝트.

프로젝트 멤버십이 포함된 쿼리의 경우 쿼리 플랜을 만들기 위해 이러한 프로젝트의 project_namespace_id가 필요할 수 있습니다. 각각 15846663(gitlab-org/gitlab용)과 15846626(gitlab-org/gitlab-foss용)입니다.

• 사용자가 포함된 쿼리의 경우 gitlab-qa 사용자(user_id = 1614863).

선택적으로 자신의 user_id나 쿼리 플랜 생성에 사용 중인 프로젝트 또는 그룹 내에서 오랜 기록을 가진 사용자의 user_id를 사용할 수도 있습니다.

즉, 어떤 쿼리 플랜도 0개의 레코드를 반환하거나 제공된 limit보다 적은 레코드를 반환해서는 안 됩니다(limit이 포함된 경우). 쿼리가 배치에 사용되는 경우, 적절한 결과가 포함된 올바른 예시 배치를 식별하여 제공해야 합니다.

`UPDATE` 구문은 항상 0개의 레코드를 반환합니다. 업데이트되는 행을 파악하려면 아래 줄을 확인해야 합니다.

예를 들어, UPDATE 구문은 0개의 레코드를 반환하지만, -> Index scan으로 시작하는 줄에서 1개의 행을 업데이트함을 확인할 수 있습니다:

EXPLAIN UPDATE p_ci_pipelines SET updated_at = current_timestamp WHERE id = 1606117348;

 ModifyTable on public.p_ci_pipelines  (cost=0.58..3.60 rows=0 width=0) (actual time=5.977..5.978 rows=0 loops=1)
  Buffers: shared hit=339 read=4 dirtied=4
  WAL: records=20 fpi=4 bytes=21800
  I/O Timings: read=4.920 write=0.000
  ->  Index Scan using ci_pipelines_pkey on public.ci_pipelines p_ci_pipelines_1  (cost=0.58..3.60 rows=1 width=18) (actual time=0.041..0.044 rows=1 loops=1)
        Index Cond: (p_ci_pipelines_1.id = 1606117348)
        Buffers: shared hit=8
        I/O Timings: read=0.000 write=0.000

쿼리가 GitLab.com의 새 기능에 속하며 프로덕션에서 데이터를 반환하지 않는 경우:

로컬 환경에서 쿼리를 분석하고 플랜을 제공할 수 있습니다.

• postgres.ai는 데이터 업데이트(exec UPDATE issues SET ...)와 새 테이블 및 칼럼 생성(exec ALTER TABLE issues ADD COLUMN ...)을 허용합니다.

EXPLAIN 플랜 이해하기에서 실제로 반환된 레코드 수를 찾는 방법에 대한 자세한 정보를 확인할 수 있습니다.

• 쿼리 변경의 경우, 변경 전후의 SQL 쿼리와 플랜을 모두 제공하는 것이 좋습니다. 이는 차이점을 빠르게 파악하는 데 도움이 됩니다.

• 가능하면 벤치마크 형태로 성능 개선을 보여주는 데이터를 포함합니다.

• 쿼리 플랜을 평가할 때, 데이터베이스에 대해 실행될 최종 쿼리가 필요합니다. 파인더와 스코프에서 ActiveRecord::Relation으로 반환되는 중간 쿼리를 분석할 필요는 없습니다. PostgreSQL 쿼리 플랜은 limit 및 최종 실행 전에 추가될 수 있는 다른 요소를 포함한 모든 최종 매개변수에 따라 달라집니다. 실제로 실행된 쿼리를 확인하는 한 가지 방법은 log/development.log를 확인하는 것입니다.

기존 테이블에 외래 키 추가 시 준비 사항#

• 외래 키를 추가하기 전에 소스 테이블에서 고아 행을 제거하는 마이그레이션을 포함합니다.

• 더 이상 필요하지 않을 수 있는 dependent: ... 인스턴스를 제거합니다.

테이블 추가 시 준비 사항#

• 테이블 칼럼 순서 지정 가이드라인에 따라 칼럼을 정렬합니다.

• 인덱스를 포함하여 다른 테이블의 데이터를 가리키는 칼럼에 외래 키를 추가합니다.

• WHERE, ORDER BY, GROUP BY, JOIN과 같은 구문에 사용되는 필드에 인덱스를 추가합니다.

• 새 테이블은 db/fixtures/development/의 파일로 시드되어야 합니다. 이 픽스처는 업그레이드가 성공적으로 완료되는지 확인하는 데도 사용되므로, 새 테이블이 항상 데이터로 채워져 있는 것이 중요합니다.

• 정적 데이터를 저장하기 위해 데이터베이스 테이블을 사용하지 않도록 합니다. 대신 고정 항목 모델을 사용하세요.

• 새 테이블과 칼럼은 반드시 위험한 것은 아니지만, 시간이 지남에 따라 일부 액세스 패턴은 확장하기 어렵습니다. 이러한 위험한 패턴을 미리 파악하기 위해 액세스 및 크기에 대한 예상치를 문서화해야 합니다. MR 설명에 다음 질문에 대한 답변을 포함하세요:

향후 3개월, 6개월, 1년 동안 새 테이블의 예상 성장률은 어떻게 됩니까? 어떤 가정을 기반으로 합니까?

• 3개월, 6개월, 1년 후에 이 테이블에 시간당 얼마나 많은 읽기 및 쓰기가 발생할 것으로 예상합니까? 어떤 상황에서 행이 업데이트됩니까? 어떤 가정을 기반으로 합니까?

• 예상 데이터 볼륨과 액세스 패턴을 기반으로, 새 테이블이 GitLab.com 또는 GitLab Self-Managed 인스턴스의 가용성에 위험을 초래합니까? 제안된 설계가 GitLab.com 및 GitLab Self-Managed 고객의 요구를 지원하도록 확장됩니까?

칼럼, 테이블, 인덱스 또는 기타 구조 제거 시 준비 사항#

• 칼럼 삭제 가이드라인을 따릅니다.

• 일반적으로(필수 규칙은 아니지만) 포스트 배포 마이그레이션에서 인덱스와 외래 키를 제거하는 것이 모범 사례입니다.

예외로 소규모 테이블의 인덱스와 외래 키 제거가 있습니다.

• 인덱스를 삭제할 때, 복합 인덱스 칼럼 순서 요구 사항을 확인하여 복합 인덱스가 대체 역할을 할 수 있는지 검증합니다.

• 복합 인덱스를 추가하는 경우 다른 인덱스가 중복될 수 있으므로, 같은 마이그레이션에서 해당 인덱스를 제거합니다. 예를 들어 index(column_A, column_B, column_C)를 추가하면 index(column_A, column_B)와 index(column_A) 인덱스가 중복됩니다.

대량 업데이트 작업 사용 시 준비 사항#

update, upsert, delete, update_all, upsert_all, delete_all 또는 destroy_all ActiveRecord 메서드를 사용할 때는 특별한 주의가 필요합니다. 이 메서드들은 데이터를 수정하고 성능이 저하될 수 있으며, 스코프가 부적절하게 지정되면 데이터를 파괴할 수 있습니다. 이 메서드들은 또한 Common Table Expression(CTE) 구문과 호환되지 않습니다. Danger는 이러한 메서드가 사용될 때 머지 리퀘스트 diff에 댓글을 남깁니다.

쿼리 추가 또는 수정 시 준비 사항 문서를 따라 원시 SQL 쿼리와 쿼리 플랜을 머지 리퀘스트 설명에 추가하고, 데이터베이스 리뷰를 요청합니다.

유용한 팁#

• 특정 브랜치에서 마이그레이션을 자주 적용하고 되돌리는 경우, 이 과정을 더 효율적으로 만들기 위해 scripts/database/migrate.rb를 사용해 볼 수 있습니다.

데이터베이스 리뷰 방법#

기본 마이그레이션 요구 사항#

• 데이터베이스 테스트 job(db:gitlabcom-database-testing)이 통과하는지 확인합니다.

• db/structure.sql이 이 머지 리퀘스트의 마이그레이션과 관련된 변경 사항만 포함하는지 확인합니다. 관련 없는 스키마 수정이 없어야 합니다.

• 마이그레이션이 되돌릴 수 있는지 확인하고 #down 메서드를 구현합니다.

• 마이그레이션이 트랜잭션 내에서 실행되거나(Rails 기본값) disable_ddl_transaction!을 사용하는 동시 작업만 사용하는지 확인합니다.

• db/schema_migrations 하위의 관련 버전 파일이 추가 또는 제거되었는지 확인합니다.

스타일 및 표준 준수#

• 마이그레이션이 데이터베이스 마이그레이션 스타일 가이드를 따르는지 확인합니다.

칼럼 순서 확인

• 외래 키에 대한 인덱스가 있는지 확인

대규모 테이블 및 크기 제한#

• 크기 임계값을 초과하는 기존 테이블에 인덱스 및 칼럼이 추가되지 않는지 확인합니다. 필요한 경우 작성자는 데이터베이스 프레임워크 팀에 예외 요청을 제출할 수 있습니다.

• 대규모 테이블에 인덱스가 추가되었고 Database Lab에서 실행 시간이 길었던 경우(1시간 이상):

비동기적으로 추가하는 단계를 따릅니다.

• 메인테이너: 머지 리퀘스트가 머지된 후, #f_upcoming_release Slack 채널에서 릴리즈 관리자에게 알립니다.

타이밍 및 성능 표준#

• 마이그레이션 타이밍 가이드라인 확인

• 쿼리 타이밍 확인(해당하는 경우): 단일 트랜잭션에서 마이그레이션에 실행되는 누적 쿼리 시간은 GitLab.com에서 15초 내에 편안하게 들어와야 하며, 가능한 한 훨씬 적어야 합니다.

• 일반 가이드라인은 쿼리가 100ms 실행 시간 이하로 유지되는 것입니다.

마이그레이션 배치 및 타이밍#

• GitLab.com에서의 실행 시간 예상치를 수립합니다.

• 적절한 마이그레이션 유형을 선택합니다.

• 데이터 마이그레이션은 되돌릴 수 있어야 하며, no-op이거나 되돌릴 수 없는 이유에 대한 주석이 있어야 합니다. 이는 모든 마이그레이션 유형(일반, 포스트 배포, 백그라운드 마이그레이션)에 적용됩니다.

백그라운드 마이그레이션 세부 사항#

• 배치된 백그라운드 마이그레이션 확인

• gitlab-com-database-testing 댓글(Database Migrations (on the main database) 등의 제목)에서 제공된 시간 예상치를 확인하여 쿼리 성능 가이드라인을 준수하는지 확인합니다.

• 백그라운드 마이그레이션은 일반적으로 다음과 같은 경우에 사용되지만 이에 한정되지는 않습니다:

대규모 테이블에서 데이터 마이그레이션

• 데이터셋의 레코드당 다수의 SQL 쿼리 실행

• 쿼리 검토(예: 배치 크기가 적절한지 확인)

• 위의 마이그레이션 배치 및 타이밍 섹션의 배치 가이드라인을 따릅니다.

새 테이블 및 칼럼 리뷰#

• 관계형 모델링 및 설계 선택 사항 검토

새 테이블이나 칼럼이 추가되는 경우 액세스 패턴 및 데이터 레이아웃을 고려합니다.

• 명시된 액세스 패턴과 볼륨이 합리적입니까? 이를 기반으로 한 가정이 타당해 보입니까? 이러한 패턴이 안정성에 위험을 초래합니까?

• 공간을 절약하기 위해 칼럼이 순서에 맞게 정렬되어 있습니까?

• 다른 테이블에 대한 참조를 위한 외래 키가 있습니까?

• 칼럼 제거의 경우, 해당 칼럼이 이전 릴리즈에서 무시되었는지 확인합니다.

쿼리 성능 분석#

• 지나치게 복잡한 쿼리와 작성자가 리뷰를 위해 특별히 지목한 쿼리(있는 경우)를 확인합니다.

• 모든 새 쿼리와 수정된 쿼리가 머지 리퀘스트 설명에 Database Lab의 SQL 구문과 쿼리 플랜을 모두 포함하는지 확인합니다.

• 주어진 쿼리에 대해 데이터 분포와 관련된 매개변수를 검토합니다.

• 쿼리 플랜 확인 및 쿼리에 대한 필요한 개선 사항을 제안합니다(예: 쿼리 재구성, 인덱스 추가/제거 등). 열린 질문이 있으면 #database_maintainers 채널에 문의하세요.

• N+1 문제를 피하고 쿼리 수를 최소화합니다.