Golang で *DB.exec() とプリペアド ステートメントを使用するという難題を解読する

はじめに

レルム内Go と Postgresql を使用したデータベース操作について、いつまでも疑問が残ります。なぜわざわざこれを行う必要があるのか​​ということです。 DB.exec() または Go が作成を自動化しているように見えるプリペアド ステートメントですか?この記事では、行を返さない操作の実行の複雑さを掘り下げ、プリペアド ステートメントの使用の背後にある理論的根拠を説明します。

DB.exec()?

DB.Query() は事実ですが、 DB.exec() は、SQL ステートメントを実行するために同じ意味で使用できますが、返される結果のタイプが異なります。 DB.exec() はクエリの影響を受ける行数に関する洞察を提供し、DB.Query() は結果セットを返します。

たとえば、次のようにします。 DELETE ステートメントを実行して、削除された行の数を確認したいとします。 DB.exec() を使用することをお勧めします。

res, err := db.Exec(`DELETE FROM my_table WHERE expires_at = $1`, time.Now())
if err != nil {
    panic(err)
}

numDeleted, err := res.RowsAffected()
if err != nil {
    panic(err)
}
print(numDeleted)

あるいは、より面倒なアプローチでは、DB.Query() を使用し、行をループしてカウントします:

rows, err := db.Query(`DELETE FROM my_table WHERE expires_at = $1 RETURNING *`, time.Now())
if err != nil {
    panic(err)
}
defer rows.Close()

var numDeleted int
for rows.Next() {
    numDeleted  = 1
}
if err := rows.Err(); err != nil {
    panic(err)
}
print(numDeleted)

さらに、クエリの結果が無関係で、クエリを実行するだけでよい場合は、DB.exec() が簡潔な解決策を提供します。

if _, err := db.Exec(``); err != nil {
    panic(err)
}

対照的に、DB.Query() を使用するときに、返された DB.Rows 値のクローズ呼び出しを省略すると、最終的にオープン接続の過負荷が発生します。メモリ リークが原因です。

プリペアド ステートメントの詳細を調べる

提案されていますが、 Go はプリペアド ステートメントを自動的に作成しますが、現実はさらに微妙なようです。 DB.Query() の動作は、使用されている基礎となるドライバーに依存しているようです。

それにもかかわらず、DB.Stmt を準備して再利用すると、頻繁に実行されるパフォーマンスを向上させることができます。クエリ。 Postgresql の公式ドキュメントを参照すると、プリペアド ステートメントがどのように操作を最適化できるかがわかります。

結論

DB.exec() とGolang のプリペアド ステートメントは、開発者が行を返さない操作を効率的に実行し、パフォーマンスの最適化を求めるときにプリペアド ステートメントの利点を活用するのに役立ちます。