本文記錄了我在實際工作中關於資料庫操作上一些小經驗，也是新手入門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