Go のデータベース/SQL が Postgres に直接クエリするよりも遅いのはなぜですか?

データベース/SQL を使用したクエリは Postgres への直接クエリより遅い

Go アプリケーションを使用してローカル Postgres インスタンスをクエリする場合、データベース/SQL を使用する場合とデータベースに直接クエリを実行する場合とでは、顕著なパフォーマンスの違いがあります。この質問では、この不一致の背後にある潜在的な原因を調査します。

背景情報

database/sql パッケージは、SQL データベースと対話するためのインターフェイスを提供します。データベースへの接続のプールを管理し、各接続を使用して複数のクエリを実行できます。ただし、database/sql を使用する場合は、接続の処理を理解することが重要です。

• 接続プール: sql.DB は、単一の接続ではなく、接続のプールを表します。プールは、接続の最大数や接続の最大存続期間などのオプションを使用して構成できます。
• 遅延接続オープン: sql.Open を使用して接続を開くと、実際の接続は確立はすぐには起こらないかもしれません。プールは、必要に応じて接続を遅延して開きます。

パフォーマンスの違いの説明

パフォーマンスの違いの主な理由は次のとおりです。

1.新しい接続の確立:

• 最初の db.Query は、データベースへの新しい接続の確立を伴うため、比較的低速です。
• 2 番目の db.Query は、次の理由によりわずかに遅くなります。プールは最初の接続を再利用するのではなく、新しい接続を開きます。 query.

解決策:

新しい接続の確立によるパフォーマンスへの影響を排除するには、次のことをお勧めします。

• 接続をプールに解放します: 各クエリが完了したら、によって返された行オブジェクトを閉じます。 db.クエリ。これにより、関連付けられた接続が解放されてプールに戻ります。
• プールを事前初期化します: プールを開いた後、クエリを実行する前に db.Ping を呼び出して、少なくとも 1 つの接続を強制的に確立します。 。これにより、最初のクエリに利用可能な接続が確保されます。

これらの最適化により、データベース/SQL クエリのパフォーマンスが大幅に向上します。

注意事項準備されたステートメント:

クエリに引数が含まれる場合は、次の点に注意することが重要です。実際には、database/sql は内部で準備されたステートメントを作成して実行します。プリペアド ステートメントは効率性の利点を提供しますが、特に引数のない単純なクエリの場合、ある程度のオーバーヘッドも伴います。

データベース/SQL の接続管理とプリペアド ステートメントの動作を理解することで、クエリのパフォーマンスを最適化し、問題を排除できます。大幅な減速。

以上がGo のデータベース/SQL が Postgres に直接クエリするよりも遅いのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。