Need to close prepared statements about go-database-sql-tutorial HOT 1 CLOSED

There are also a few subtleties about how the package prepares and uses statements. There are some best-effort things that can cascade out of control when concurrency becomes high and new connections are opened because the connection a statement used to prepare isn't available at the time it's needed. This can result in statements being re-prepared a lot without being closed inside the server, and potentially causing issues on MySQL in particular (running over the limit).

Gustavo Kristic wrote the following to me privately, which I think is good reading. The context is that we were seeing some of these problems and trying to use VividCortex's metrics on statement prepare/close counts to figure out which statements were not being closed:

QueryRow() has no difference from Query() regarding the preparedness of statements; it's only a convenience wrapper on the later in terms of result handling.

In my opinion the problem is Go's underlying database/sql implementation. Prepared statements are kept in the package per connection in the connection pool. When you try to run a previously prepared statement, Go tries to use the connection where the statement was prepared. But if that's not possible (cause the connection is already busy) then it will go ahead and prepare the statement again using a different connection, that will now end up running the required statement. (Also, if a connection is eventually dropped you won't see any close for all statements that were prepared for it. That may as well account for some difference.) This behavior is transparent for applications using database/sql and cannot be changed. It's at the core of the package.

Let me stress something: you won't see the number of prepared statements increasing if throughput is not high enough. The database/sql package will always favor connections where the statement has already been prepared. It will resort to a different connection only if the former is busy at that particular moment, which usually means the server is doing a lot of work in parallel.

from go-database-sql-tutorial.