一般的なコンセンサスは、直接クエリされたステートメントはパラメーターを許可せず、準備されたステートメントは許可するということです。
ただし、Go の database/sql パッケージでは、ODBC パラメーターを使用して、パラメーターを db.QueryRow() や db.Query() などに送信できます。したがって、それらは機能的に同等であるように見えます。
そうは言っても、最初にステートメントを作成し、次にそれを実行するポイントは何ですか? ステートメントが最初にデータベースに対してコンパイルされるとしましょう。余分なトリップを追加しているため、負荷が増加し、パフォーマンスが低下しませんか? そして、Query/QueryRow からパラメーターを取得できるので、ステートメントが悪いことになりませんか?
理論的には、データベース サーバーが単純な SQL ステートメント (またはバッチ) を受け取ると、それをコンパイルする必要があります。それを何らかの内部形式に解析し、いわゆる「クエリ プラン」を準備します。これは一連の操作 (インデックスやテーブルなど)スキャン、比較など) 実際の要求を実行します。これらすべてを実行すると、特定のサーバー リソースが明らかに消費されます。非常に多くの DBMS が「準備されたステートメント」をサポートし始めました。サーバーは解析/計画ステップを 1 回だけ実行し、結果に「ハンドル」を渡します。その後、複数回「呼び出し」、異なるパラメーターを指定するだけです。
では、より複雑な領域に移りましょう。
最初に注意すべきことは、メモリと処理能力が安くなったとき、コモディティ サーバーからハイエンド サーバーで実行されている DBMS は、クエリを処理する際により多くのリソースを使用できるようになったため、一部のDBMS はユーザー クエリをキャッシュすることです。つまり、単純なクエリ (SQL ステートメントまたはバッチ) を実行すると、サーバーは通常の解析/クエリ計画をすべて実行しますが、結果を保存し、後で同じクエリに遭遇した場合は、処理部分をスキップして実行するだけです。データに対する操作。
2 番目に注意すべきことは、プログラミング言語/ライブラリは、データベース エンジンにアクセスするための特定の共通インターフェイス (ODBC forCは一例であり、database/sqlforGoは別の例であり、他にも無数にある) をプログラマーに提示する傾向がある一方で、ワイヤ プロトコルまたはその他のサーバーへの実際のアクセス方法は大幅に異なる場合があります。たとえば、あるデータベース サーバーはワイヤ プロトコルでクエリと共にパラメータを渡すことをサポートしている場合がありますが、別のデータベース サーバーはサポートしていない場合があるため、アクセス レイヤーはパラメータをエスケープされた SQL リテラルに変換し、それらをクエリに埋め込んでサーバーに送信する必要があります。 .
これらすべてから取得する必要がある主なアイデアは、データベースエンジンが異なり、プログラムによってデータベースに集中的な負荷をかけることを計画している場合は、データベースエンジンの詳細を知る必要があることです. DMBS のワイヤ プロトコルでできることとできないこと、DBMS の接続確立が速いかどうかなどを確認します。特定の DBMS のパフォーマンスの最適化に関するドキュメントを探してください。