一 . Go 數(shù)據庫簡介
在Go中訪問數(shù)據庫需要用到sql.DB接口：它可以創(chuàng)建語句(statement)和事務(transaction)，執(zhí)行查詢，獲取結果。
sql.DB并不是數(shù)據庫連接，也并未在概念上映射到特定的數(shù)據庫(Database)或模式(schema)。它只是一個抽象的接口，不同的具體驅動有著不同的實現(xiàn)方式。通常而言，sql.DB會處理一些重要而麻煩的事情，例如操作具體的驅動打開/關閉實際底層數(shù)據庫的連接，按需管理連接池。
sql.DB這一抽象讓用戶不必考慮如何管理并發(fā)訪問底層數(shù)據庫的問題。當一個連接在執(zhí)行任務時會被標記為正在使用。用完之后會放回連接池中。不過用戶如果用完連接后忘記釋放，就會產生大量的連接，極可能導致資源耗盡（建立太多連接，打開太多文件，缺少可用網絡端口）
二 .常用的API及使用
1.導入驅動
2.建立連接
3. 單行查詢
4.多行查詢
5. 添加記錄
6.? 刪除操作
7. 更新操作
8.事務
特別提醒：
》資源耗盡
不謹慎地使用database/sql會給自己挖許多坑，最常見的問題就是資源枯竭（resource exhaustion）：
打開和關閉數(shù)據庫（sql.DB）可能會導致資源枯竭；
結果集沒有讀取完畢，或者調用rows.Close()失敗，結果集會一直占用池里的連接；
使用Query()執(zhí)行一些不返回結果集的語句，返回的未讀取結果集會一直占用池里的連接；
不了解準備語句（Prepared Statement）的工作原理會產生許多額外的數(shù)據庫訪問。
》Uint64
Go底層使用int64來表示整型，使用uint64時應當極其小心。使用超出int64表示范圍的整數(shù)作為參數(shù)，會產生一個溢出錯誤：
// Error: constant 18446744073709551615 overflows int_, err := db.Exec("INSERTINTOusers(id)VALUES", math.MaxUint64)
這種類型的錯誤非常不容易發(fā)現(xiàn)，它可能一開始表現(xiàn)的很正常，但是溢出之后問題就來了
》不合預期的連接狀態(tài)
連接的狀態(tài)，例如是否處于事務中，所連接的數(shù)據庫，設置的變量等，應該通過Go的相關類型來處理，而不是通過SQL語句。用戶不應當對自己的查詢在哪條連接上執(zhí)行作任何假設，如果需要在同一條連接上執(zhí)行，需要使用Tx。
舉個例子，通過USE DATABASE改變連接的數(shù)據庫對于不少人是習以為常的操作，執(zhí)行這條語句，只影響當前連接的狀態(tài)，其他連接仍然訪問的是原來的數(shù)據庫。如果沒有使用事務Tx，后續(xù)的查詢并不能保證仍然由當前的連接執(zhí)行，所以這些查詢很可能并不像用戶預期的那樣工作。
更糟糕的是，如果用戶改變了連接的狀態(tài)，用完之后它成為空連接又回到了連接池，這會污染其他代碼的狀態(tài)。尤其是直接在SQL中執(zhí)行諸如BEGIN或COMMIT這樣的語句
》驅動的特殊語法
盡管database/sql是一個通用的抽象，但不同的數(shù)據庫，不同的驅動仍然會有不同的語法和行為。參數(shù)占位符就是一個例子。
》批量操作
出乎意料的是，標準庫沒有提供對批量操作的支持。即INSERT INTO xxx VALUES (1),(2),...;這種一條語句插入多條數(shù)據的形式。目前實現(xiàn)這個功能還需要自己手動拼SQL。
》執(zhí)行多條語句
database/sql并沒有對在一次查詢中執(zhí)行多條SQL語句的顯式支持，具體的行為以驅動的實現(xiàn)為準。所以對于
_, err := db.Exec("DELETEFROM tbl1;DELETEFROM tbl2") // Error/unpredictable result
這樣的查詢，怎樣執(zhí)行完全由驅動說了算，用戶并無法確定驅動到底執(zhí)行了什么，又返回了什么。
》事務中的多條語句
因為事務保證在它上面執(zhí)行的查詢都由同一個連接來執(zhí)行，因此事務中的語句必需按順序一條一條執(zhí)行。對于返回結果集的查詢，結果集必須Close()之后才能進行下一次查詢。用戶如果嘗試在前一條語句的結果還沒讀完前就執(zhí)行新的查詢，連接就會失去同步。這意味著事務中返回結果集的語句都會占用一次單獨的網絡往返。
