Connection pool to connect to the database in go: When you need to communicate with the database, you pull a connection from the connection pool and interact with the database. Unused connections that are exhausted go back to the connection pool and wait for the next call. If there is no idle connection in the connection pool, a new connection is created automatically. There is one paragraph:
an SQL. Row returns the connection when Scan () is called, SQL. Rows returns either when Close () are called or all rows are been iterated over with Next (), and sql . Tx would return when Commit or Rollback () is called. If you forget to completely iterate an SQL. Rows and you forget to Close it, that connection'll never go back to the pool.
As you can see from above, SQL. If row does not traverse or call the close () method directly, the connection that executes this query will persist! When the available connections in the connection pool have been exhausted, a new connection is created. This is why calling Setmaxopenconns is useless because this function simply sets the number of connections in the connection pool! If the connection pool is killed because the connection is not released in time, a new connection will be created continuously until all the MySQL connections are exhausted and an error is made. After understanding, add the following function in all calls to Db.query:
Defer row. Close ()
so the query connection can be closed at the end of the function or an exception, You will not continue to create a new connection. Full thought this can solve the problem, but server is running, the same error still occurs over time. monitoring page, you can see the number of MySQL connections is soaring after the program runs. The problem becomes more and more solvable, and you can only check the code again in one line.
Functions in Go can have multiple return values, using underscores to ignore unwanted return values:
_, Err: = M.db. Query ("SQL")
SQL statements such as update and Del in the program do not require a return value and are ignored directly. Guess this is also impossible to release the connection, because even if you do not accept the return value, does not mean that the variable does not exist. That is, the SQL returned. Row still exists, but you do not receive it. Did not receive, not to mention the release of the connection, so the final generation of a large number of connections continue to error. Look back at the article and see this paragraph:
Ping and Exec would release the connection right before returning, but the others would pass ownership of the connection to The result, whether that's an SQL. Row, SQL. Rows, or SQL.TX.
This means that the ping and Exec methods will automatically release the connection after the call is complete. Change all the statements in the code that do not need the return value to be executed by the Exce method, go run, OK, the number of connections is finally normal!
The problem is solved, always up to pay attention to something:
The program connected to the database will have a connection leak situation, need to release the connection in time
The connection to query and Queryrow two methods in the Go SQL package does not automatically release the connection, only if the result is traversed or the Close method is called to close the connection
The Ping and Exec methods in Go SQL will automatically release the connection after the call is finished
Ignoring a return value of a function does not mean that the value does not exist, and if the return value requires close to release the resource, ignoring it directly causes a resource leak.
A variable with a close method, which is invoked immediately after use to release the resource
Go connect MySQL database too many connections