繰り返し SQL クエリを実行するためのベスト プラクティスと考えられるものは何ですか? 私の理解では、パラメーター化されたクエリを使用し、最初の実行時にそれを準備済みステートメントに変換します。このクエリを複数のスレッドで実行する必要がある場合はどうすればよいでしょうか? 各スレッドのクエリの種類ごとに準備済みステートメントを作成する必要がありますか? それとも、最近では SQL ステートメントの解析が非常に効率的になり、準備済みステートメントは不要になったのでしょうか?
2 に答える
使用している環境については触れていませんが、一般的に、ストアド プロシージャも検討できます (DB エンジンがサポートしている場合)。これには、データベース自体に追加の抽象化レイヤーを構築するという利点があるため、正確なデータベース スキーマをクライアント アプリケーションとの関連性を低くすることができます。
ほとんどの場合、パラメーター化されたクエリを使用することをお勧めします。これは、パフォーマンスのためだけでなく、SQL インジェクションに対するセキュリティとデータ型変換の問題 (ローカライズされた日時) を防ぐためでもあります。
良い質問です。一度に 1 つずつ答えます。
- 繰り返し SQL クエリを実行するためのベスト プラクティスと考えられるものは何ですか?
パラメータの違いを除いてクエリが繰り返される場合は、準備済みステートメントを使用します。
- 私の理解では、パラメーター化されたクエリを使用し、最初の実行時にそれを準備済みステートメントに変換します。
それが、何をすべきかについての私の意見です。古典的には、プログラムの開始時にすべてのクエリを準備することをお勧めします。私の見解では、これは常にナンセンスでした。サーバーがクエリで過負荷になり、その多くは特定の実行で使用されず、クライアントと DBMS の両方でメモリが浪費されます。要求に応じて声明を準備することは常に最も賢明でした。それが最初に必要になったときであり、必要でない限りではありません。「常に」実行されるステートメントの例外を許可しますが、「常に」が実際には 100% に近いと確信する必要があります。
- このクエリを複数のスレッドで実行する必要がある場合はどうすればよいでしょうか? 各スレッドのクエリの種類ごとに準備済みステートメントを作成する必要がありますか?
これは、さまざまなスレッドが DBMS と通信する方法によって異なります。私がよく知っている DBMS では、すべてのスレッドが共有する 1 つの接続があれば、1 つの接続に対して 1 回準備するだけで済みます。各スレッドに独自の個別の接続がある場合は、スレッドごとに個別にステートメントを準備する必要があります。
- それとも、最近では SQL ステートメントの解析が非常に効率的になり、準備済みステートメントは不要になったのでしょうか?
マシンは高速です - はい。また、繰り返されないステートメントの場合、オーバーヘッドについて心配する価値はありません。ただし、クエリを数百万回実行する場合は、数百万回準備するためのコストが加算され始めます。また、データベースサーバーマシンは通常共有リソースですが、ステートメントはユーザーごとに個別に準備される可能性が高いため、複数のユーザーが破棄されるクエリを繰り返してシステムを叩いている場合、サーバーはクエリを準備するのに忙しすぎて実行できません。それらの高速。
だから、私の答えは「いいえ」です。クエリが十分に頻繁に繰り返される場合、準備済みステートメントは依然として有益です。何百回も - 準備済みステートメントを使用します。数十回 - おそらく準備済みステートメントを使用します。それ未満 - おそらく準備済みステートメントを使用しないでください。