本文記錄了我在實際工做中關於數據庫操做上一些小經驗,也是新手入門golang時我認爲必定會碰到問題,沒有什麼高大上的東西,因此但願能拋磚引玉,也算是對這個問題的一次總結。html
其實我也是一個新手,機緣巧合幾個月前開始作golang開發,之前一直是以.NET技術棧爲主,文章若有錯誤不吝指正。java
相信你們第一次碰到這個問題的時候應該和我同樣,去網上找個例子參考一下。沒錯,這樣的例子一搜一大把,因而咱們很容易(抄)寫了以下一段代碼:mysql
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"。因而把這段代碼封裝成一個公共方法供其餘地方調用:git
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了,不過事情可沒這麼簡單。github
很快, 編碼五分鐘捉蟲兩小時開場了。golang
慢慢的我就發現,在連續屢次操做數據庫後就偶爾發生程序卡死的狀況,請求一直是pending狀態,只能殺死進程重啓才能夠。剛開始沒在乎,也沒有懷疑是數據庫操做有問題,但後來愈來愈頻繁嚴重影響到程序開發,沒辦法就記log加斷點調試看是哪裏出了問題。通過反覆驗證後肯定問題就出在執行SQL語句這裏,這下懵了,我看網上你們都是這麼寫的怎麼會有問題??sql
根據多年開發經驗,大膽猜想SQL執行失敗最大的可能性就是數據庫鏈接不上,在確認數據庫沒有崩掉的狀況下開始研究代碼哪裏寫的不對,可是先後也就那麼幾行代碼實在看不出什麼毛病,只能開始深刻了研究database/sql包的知識點。數據庫
經過查資料發現open完數據庫後的返回對象sql.DB
其實是一個鏈接池對象,並非單純的某一個鏈接。它是一個抽象的數據訪問接口,和數據庫類型無關,固然也就和具體的數據庫Schema無關。咱們要實現某一個數據庫的訪問單純用這個包是不夠的,還要引入具體的數據庫驅動包,這個驅動纔是真正實現數據庫訪問的東西。less
如今再回過頭來看代碼,既然open建立了鏈接池,那用完把它銷燬不就行了,因而參考官網文檔稍加改進:tcp
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包提供了幾個鏈接池配置參數,主要包含:
通過以上分析,能夠清晰的知道最開始的bug就是由於錯誤地使用了鏈接池致使數據庫鏈接被耗光從而沒法執行SQL語句,其實說簡單也很簡單。
以上就是工做中使用golang訪問數據庫的踩坑歷程,但願能幫到新接觸golang的朋友,若有錯誤的地方歡迎指出,以避免誤導他人。
http://go-database-sql.org/accessing.html