本文記錄了我在實際工作中關於數據庫操作上一些小經驗，也是新手入門golang時我認為一定會碰到問題，沒有什么高大上的東西，所以希望能拋磚引玉，也算是對這個問題的一次總結。
其實我也是一個新手，機緣巧合幾個月前開始做golang開發，以前一直是以.NET技術棧為主，文章如有錯誤不吝指正。
訪問數據庫
相信大家第一次碰到這個問題的時候應該和我一樣，去網上找個例子參考一下。沒錯，這樣的例子一搜一大把，於是我們很容易(抄)寫了如下一段代碼：
import (
"fmt"
"database/sql"
_ "github.com/go-sql-driver/mysql"
)
func main() {
db, err := sql.Open("mysql","root:111111@tcp(127.0.0.1:3306)/testdb")
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
fmt.Println("Successfully connected!")
}
把程序運行起來一看，成功地輸出了想看到的東西，內心一陣暗喜“so easy"。於是把這段代碼封裝成一個公共方法供其他地方調用：
func GetDbContext() *sql.DB {
db, err := sql.Open("mysql","root:111111@tcp(127.0.0.1:3306)/testdb")
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
return db
}
func DoSomething(){
db := GetDbContext()
rows,_ := db.Query("select * from table1")
}
沒錯我最早就是這么干的，然后開始愉快地轉頭寫CRUD了，不過事情可沒這么簡單。
很快， 編碼五分鍾捉蟲兩小時開場了。
慢慢的我就發現，在連續多次操作數據庫后就偶爾發生程序卡死的情況，請求一直是pending狀態，只能殺死進程重啟才可以。剛開始沒在意，也沒有懷疑是數據庫操作有問題，但后來越來越頻繁嚴重影響到程序開發，沒辦法就記log加斷點調試看是哪里出了問題。經過反復驗證后確定問題就出在執行SQL語句這里，這下懵了，我看網上大家都是這么寫的怎么會有問題？？
連接池問題
根據多年開發經驗，大膽猜測SQL執行失敗最大的可能性就是數據庫連接不上，在確認數據庫沒有崩掉的情況下開始研究代碼哪里寫的不對，但是前后也就那么幾行代碼實在看不出什么毛病，只能開始深入了研究database/sql包的知識點。
通過查資料發現open完數據庫后的返回對象sql.DB實際上是一個連接池對象，並不是單純的某一個連接。它是一個抽象的數據訪問接口，和數據庫類型無關，當然也就和具體的數據庫Schema無關。我們要實現某一個數據庫的訪問單純用這個包是不夠的，還要引入具體的數據庫驅動包，這個驅動才是真正實現數據庫訪問的東西。
現在再回過頭來看代碼，既然open創建了連接池，那用完把它銷毀不就好了，於是參考官網文檔稍加改進：
func GetDbContext() *sql.DB {
db, err := sql.Open("mysql","root:111111@tcp(127.0.0.1:3306)/testdb")
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
return db
}
func DoSomething(){
db := GetDbContext()
defer db.Close()
rows,_ := db.Query("select * from table1")
}
看似行得通，但是估計沒人願意這樣做。原因很明顯，別的先不談，創建和銷毀連接池開銷太大了，你這樣對它於心何忍，拿着屠龍刀去砍柴。
使用連接池的好處就是不需要開發者頻繁地創建和銷毀連接，這兩項工作都交給了連接池去做，我們只需要在使用前找它要一個可用的連接，用完還回去就可以了。
這里引用一段官方文檔中的原話：
Although it’s idiomatic to Close() the database when you’re finished with it, the sql.DB object is designed to be long-lived. Don’t Open() and Close() databases frequently. Instead, create one sql.DB object for each distinct datastore you need to access, and keep it until the program is done accessing that datastore. Pass it around as needed, or make it available somehow globally, but keep it open. And don’t Open() and Close() from a short-lived function. Instead, pass the sql.DB into that short-lived function as an argument.
核心意思就是sql.DB是一個長生命周期對象，你不要隨便打開和關閉，並且建議你在程序中為每一個數據庫創建唯一的sql.DB。
那么現在的問題就是如何保證程序中只有一個連接池呢？
很簡單，使用一個全局變量即可，有點類似C#和java中static的味道，在Golang中可以使用如下方法聲明一個全局對象：
package demo
import (
"database/sql"
)
var mydb,_ = sql.Open("mysql","connection_string")
不過我們的業務場景比較特殊，系統中有很多個數據庫，要根據不同參數去連不同數據庫，那么上面這種聲明賦值方式就不行了，我稍加改進，結合map實現了連接池動態管理：
var envdbMap map[string]*sql.DB
func GetEnvDbContext(connector config.DbConnector) *sql.DB {
if envdbMap == nil {
envdbMap = make(map[string]*sql.DB)
}
db, ok := envdbMap[connector.ID]
if ok {
return db
} else {
connStr := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s sslmode=disable", connector.Host, connector.Port, connector.UserName, connector.Password, connector.DatabaseName)
db, err := sql.Open("postgres", connStr)
envdbMap[connector.ID] = db
return db
}
}
原理很簡單，就是用map裝池子，池子裝連接。
有借有還
到這里連接池已經准備好了，那么如何從池子中取一個可用的連接呢？這點池子已經幫大家考慮的很周到了，大家不需要寫額外代碼去獲取連接，直接拿起池子用就可以了，內部會有一系列機制幫你弄到一個連接去執行SQL，以后有機會對池子的原理來做個解析。
但是用完要記得還回去，這個必須你手動去做，例如：
rows,_ := db.Query("select * from table1")
defer rows.Close()
// do sth...
最好不要在do sth之后做Close，因為一旦你這個過程中發生異常，導致后面的Close無法執行，那么這個連接就一直被占用，日積月累TCP連接就被你耗光了。
官方文檔說了，rows.Close()是一種無害（harmless）操作，你可以做多次，但是不能忘了做。
這里有個特殊情況要注意，對於那種沒有返回結果的SQL語句，千萬不要使用Query方法去執行，這會導致無法回收連接，這時候推薦使用Exec方法去執行。
配置連接池
默認情況下連接池沒有數量限制，但是我們的機器有TCP的數量限制，不要因為一個程序拖死一台機器，所以不推薦無限量的去使用。database/sql包提供了幾個連接池配置參數，主要包含：
- db.SetMaxIdleConns(N) 設置空閑連接的數量
- db.SetMaxOpenConns(N) 設置打開的連接數量
- db.SetConnMaxLifetime(duration) 設置連接的生存時間
詳細的介紹大家可以參考官方文檔。
總結
經過以上分析，可以清晰的知道最開始的bug就是因為錯誤地使用了連接池導致數據庫連接被耗光從而無法執行SQL語句，其實說簡單也很簡單。
以上就是工作中使用golang訪問數據庫的踩坑歷程，希望能幫到新接觸golang的朋友，如有錯誤的地方歡迎指出，以免誤導他人。
參考連接
http://go-database-sql.org/accessing.html