Go中连接数据库的连接池：当你需要和数据库通信时，就会从连接池里面取出一个连接，和数据库交互。使用完的闲置的连接会回到连接池，等待下一次的调用。如果连接池里面没有闲置的连接，会自动创建一个新的连接出来。其中有一段：
An sql.Row returns the connection when Scan() is called, sql.Rows returns either when Close() is called or all rows have been iterated over with Next(), and sql.Tx will return when Commit or Rollback() are called. If you forget to completely iterate an sql.Rows and you forget to Close it, that connection will never go back to the pool.
从上面可以看到，sql.Row如果不遍历完或者直接调用Close()方法，执行这次查询的连接就会一直存在！当连接池里的可用连接用光后，就开始创建新的连接。这就是为什么调用SetMaxOpenConns没有用的原因，因为这个函数只是设置连接池里的连接数而已！如果因为不及时释放连接而让连接池干掉了，还是会不断的创建新的连接，直到用光MySql所有的连接，报错。明白以后，在所有调用DB.Query的函数里加上了：
defer row.Close()
这样查询连接就能在函数结束或者异常的情况下被关闭，就不会持续创建新的连接了。满以为这样就可以解决问题了，但是服务器运行了以后，过段时间仍然会出现相同的错误。在phpMyadmin里的监控页面，可以看到程序运行以后MySql的连接数猛增。问题又变得无解了，只能重新一行行检查代码。
Go中的函数可以有多个返回值，使用下划线可以忽略不需要的返回值：
_, err := m.DB.Query("sql")
程序中update和del之类的sql语句不需要返回值，就直接忽略了。猜想这样也是没法释放连接的，因为即使你不接受返回值，不代表这个变量就不存在了。也就是说返回的sql.Row还是存在的，只是你没有接收而已。没接收，就更谈不上释放连接了，所以最后产生了大量的连接继续报错。回头看看那篇文章，看到这么一段：
Ping and Exec will release the connection right before returning, but the others will pass ownership of the connection to the result, whether that‘s an sql.Row, sql.Rows, or sql.Tx.
也就是说Ping和Exec方法在调用完之后，会自动释放连接。把代码中所有不需要返回值的语句改成由Exce方法执行，go run 一下，ok，连接数终于正常了！
问题是解决了，总起来以后要注意一下的东西：
- 程序连接数据库会有连接泄漏的情况，需要及时释放连接
- Go sql包中的Query和QueryRow两个方法的连接不会自动释放连接，只有在遍历完结果或者调用close方法才会关闭连接
- Go sql中的Ping和Exec方法在调用结束以后就会自动释放连接
- 忽略了函数的某个返回值不代表这个值就不存在了，如果该返回值需要close才会释放资源，直接忽略了就会导致资源的泄漏。
- 有close方法的变量，在使用后要及时调用该方法，释放资源