PostgreSQL は、高度なデータ型、インデックス、クエリ言語をサポートする、成熟した安定したリレーショナルデータベース管理システムです。ただし、PostgreSQL は
パフォーマンスと信頼性の点で優れていますが、SQL が遅い場合があります。
この記事では、PostgreSQL の SQL が遅い理由と、PostgreSQL データベースの最適化と管理を改善するための最適化ソリューションについて説明します。

SQLが遅い原因

SQL が遅いという現象は、さまざまな要因によって発生する可能性があります。最も一般的な理由のいくつかを以下に示します。

1.1. 複雑なクエリ文

複雑なクエリステートメントは通常、より多くの時間とリソースを消費し、結果として SQL が遅くなります。クエリに複数のサブクエリとユニオンが含まれている場合、パフォーマンスのボトルネックが発生する可能性があります。

1.2. インデックスの欠落

SQL クエリを実行するとき、データベースはテーブル内の条件を満たすデータを検索する必要があります。テーブル内のデータ量が多い場合、インデックスを作成してもクエリ速度が低下することはありません。

1.3. データベーステーブルが大きすぎる

データベーステーブルが大きすぎると、データの読み取りと書き込みの速度が遅くなります。これにより、SQL が遅くなる可能性があります。

1.4. メモリの不適切な使用

PostgreSQL は共有メモリを使用してパフォーマンスを向上させます。メモリが適切に使用されていない場合、SQL クエリの実行が遅くなる可能性があります。

1.5. 不十分なハードウェア構成

CPU、メモリ、ハードディスクの容量不足など、ハードウェア構成が不十分な場合、SQLが遅くなる可能性があります。

1.6. バージョンが低すぎる

PostgreSQL のバージョンが低すぎるため、パフォーマンスが新しいバージョンほど良くない可能性があります。

SQLが遅い場合の解決策

1. セッションを閉じる

遅い SQL の実行セッションをクエリし、プロセスを終了します。
データベースのバックグラウンド接続プロセスを表示する

SELECT count(*) FROM pg_stat_activity;

SELECT * FROM pg_stat_activity;

データベースのバックグラウンド接続プロセスを表示しますが、この SQL には現在のクエリプロセスが含まれていません

SELECT count(*) FROM pg_stat_activity WHERE NOT pid=pg_backend_pid();

SELECT * FROM pg_stat_activity WHERE NOT pid=pg_backend_pid();

クエリ実行時間が 1 秒を超える SQL など、現在の遅い SQL を表示します。

select * from pg_stat_activity where state<>'idle' and now()-query_start > interval '1 s' order by query_start ;

接続は **pg_terminate_backend()** を使用して終了できます。この機能を使用するには、スーパーユーザーである必要があります。これはすべてのオペレーティングシステムで同じです。

SELECT
    pg_terminate_backend(pid)
FROM
    pg_stat_activity
WHERE
    -- 不删除当前连接
    pid <> pg_backend_pid()
    -- 不删除当前连接数据库database_name的连接
    AND datname = 'database_name'
    ;

2. バージョンアップ：

パフォーマンスと機能を向上させるために、PostgreSQL バージョンを最新バージョンにアップグレードします。

サーバーのバージョンを確認する

2.1 詳細情報を表示する

SELECT version();

2.2 バージョン情報の表示

SHOW server_version;

2.3 マイナーバージョン番号を含むデジタルバージョン情報の表示

SHOW server_version_num;

新しいバージョンにアップグレードしてください。

3. メモリとキャッシュを最適化する

Shared_buffers、effective_cache_size 、その他のパラメータなどのPostgreSQLメモリ設定を調整します。

PostgreSQL の最高のパフォーマンスを実現するには、pg_tune などの PostgreSQL 最適化ツールを使用する必要もあります。このツールは、システムのメモリサイズ、I/O、ネットワークパフォーマンスに応じて PostgreSQL パラメータを調整できます。たとえば、一般的に使用されるshared_buffersとEffective_cache_sizeは、ファイルへのアクセスとメモリキャッシュの維持に関連する重要なパラメータであり、PostgreSQLがディスクファイルにアクセスする頻度を制御できます。これに加えて、wal_buffers を増やして書き込みパフォーマンスを向上させるなど、テスト結果に基づいて変更を加えることができます。これは、PostgreSQL の書き込み操作を最高レベルに高めるのに役立ちます。

最後に、PostgreSQL カーネルのパフォーマンスの正しいチューニングと最適化には、PostgreSQL パラメーター設定とサーバー構成という 2 つの要素が含まれている必要があります。したがって、データベース管理者やパフォーマンス調整者にとって、正しいパフォーマンス調整の最適化には多くの時間がかかりますが、PostgreSQL の最高のパフォーマンスを達成するためには必要な方法でもあります。

たとえば、PostgreSQL のパフォーマンスを向上させるには、次のコードを使用できます。

ALTER SYSTEM SET shared_buffers = '1000MB';

ALTER SYSTEM SET effective_cache_size = '2000MB';

ALTER SYSTEM SET wal_buffers = '12MB';

通常、shared_buffers の値はマシンメモリ全体の 15% ～ 25% に設定する必要があります。

Effective_cache_size パラメータにより、オペレーティングシステムとデータベースはディスクキャッシュに使用できるメモリの量を評価し、PostgreSQL クエリプランはメモリを RAM に固定する必要があるかどうかを決定します。値が大きい場合はインデックススキャンが使用される可能性が高く、値が小さい場合は順次スキャンが使用されます。effecve_cache_size をマシンの合計 RAM の 50% に設定することをお勧めします。

wal バッファは、先行書き込みログ (wal) バッファです。バッファのデフォルトサイズは、wal_buffers 設定によって設定されます (初期値は 16MB)。調整するシステムに多数の同時接続がある場合、wal_buffers の値が大きいほどパフォーマンスが向上します。

4. 合理的なインデックス作成

データベーステーブルの構造、適切なインデックスを確立すると、クエリのパフォーマンスが大幅に向上します。
注:
navicat を使用し、データベースを選択し、右クリックして「メンテナンス」→「インデックスの再構築」を行うことができます。

ここに画像の説明を挿入

5. テーブル設計の最適化

クエリ内の不要なデータの量を減らすために、テーブルをできるだけ小さく互いに独立した意味のある論理部分に分割します。

6. 適切な拡張機能をインストールして使用します

pgTune や pgBadger などの PostgreSQL パフォーマンスチューニングツールや、pg_hint_plan や pg_stat_statements などの拡張機能をインストールします。

PostgreSQL の遅い SQL の詳細な分析: 明らかになった理由と最適化ソリューション