クエリ・パフォーマンス・ガイドライン

このドキュメントでは、SQL クエリを最適化する際に従うべきさまざまなガイドラインについて説明します。

SQLクエリを最適化する際に注意すべき点は2つあります：

クエリの実行時間です。これは、ユーザーがGitLabをどのように体験するかを反映するので、最も重要です。
クエリプラン。クエリプランを最適化することは、クエリが時間とともに独立してスケールできるようにする上で重要です。クエリが劣化する前に、テーブルが大きくなってもインデックスがクエリのパフォーマンスを維持することを理解することは、私たちがこれらのプランを分析する理由の一例です。

クエリのタイミングガイドライン

クエリの種類	最大クエリ時間	備考
一般クエリ	`100ms`	これは難しい制限ではありませんが、もしクエリがこの制限を超えるようであれば、なぜ最適化できるのか、またはできないのかを理解するために時間を費やすことが重要です。
マイグレーションにおけるクエリ	`100ms`	総マイグレーション時間とは異なります。
マイグレーションにおける同時オペレーション	`5min`	並行オペレーションはデータベースをブロックしませんが、GitLabの更新をブロックします。これには`add_concurrent_index` や`add_concurrent_foreign_key` のようなオペレーションが含まれます。
マイグレーション後の同時オペレーション	`20min`	並行オペレーションはデータベースをブロックしませんが、GitLabのポスト更新プロセスをブロックします。これには`add_concurrent_index` や`add_concurrent_foreign_key` のようなオペレーションが含まれます。インデックス作成が20分を超える場合は、非同期インデックス作成を検討してください。
バックグラウンドマイグレーション	`1s`
サービスPing	`1s`	詳細はService Ping のドキュメントをご覧ください。

クエリのパフォーマンスを分析する際には、表示されている時間がコールドキャッシュであるかウォームキャッシュであるかに注意してください。これらのガイドラインは両方のキャッシュタイプに適用されます。
バッチクエリを扱う場合、範囲とバッチサイズを変更し、クエリのタイミングとキャッシュにどのような影響があるかを確認します。
既存のクエリのパフォーマンスが悪い場合は、それを改善する努力をしてください。それが複雑すぎたり、開発が滞ってしまうようであれば、フォローアップを作成し、タイムリーにアドレスが取れるようにします。データベースのレビュアーやメンテナーにいつでもヘルプや指導を求めることができます。

クエリのパフォーマンスを評価する場合、コールドキャッシュとウォームキャッシュのクエリの違いを理解することが重要です。

クエリが最初に作成されるときは、「コールドキャッシュ」上で作成されます。つまり、ディスクから読み込む必要があります。再度クエリを実行する場合、データはキャッシュ、PostgreSQLでは共有バッファと呼ばれるものから読み込むことができます。これが “ウォームキャッシュ “クエリです。

EXPLAIN の計画を分析する場合、タイミングだけでなく、Buffers の出力を見ることで、EXPLAIN(analyze, buffers)で説明した実行との違いを見ることができます。Database Labは自動的にこれらのオプションを含みます。

ウォームキャッシュのクエリを作成している場合、shared hits のみが表示されます。

例えば、Database Lab：

Shared buffers:
  - hits: 36467 (~284.90 MiB) from the buffer pool
  - reads: 0 from the OS file cache, including disk I/O

あるいは、psql からの説明プランで：

Buffers: shared hit=7323

キャッシュがコールドの場合、reads 。

Shared buffers:
  - hits: 17204 (~134.40 MiB) from the buffer pool
  - reads: 15229 (~119.00 MiB) from the OS file cache, including disk I/O

psql ：

Buffers: shared hit=7202 read=121