用 github.com/go-sql-driver/mysql
，不是 database/sql
本身
database/sql是 Go 标准库的抽象接口，不直接连 MySQL；真正干活的是第三方驱动。目前最稳定、最常用、官方文档默认推荐的驱动就是
github.com/go-sql-driver/mysql。它完全兼容
database/sql接口，所有
sql.Open、
db.Query、
stmt.Exec等调用都靠它底层实现。
常见错误现象：
import "database/sql"后直接运行报
sql: unknown driver "mysql" (forgotten import?)—— 就是因为只引了标准库，没导入实际驱动。 必须显式导入驱动：
import _ "github.com/go-sql-driver/mysql"（注意前面的下划线） 连接字符串格式为：
user:password@tcp(127.0.0.1:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
parseTime=True才能让
time.Time正确解析 DATETIME 字段；
loc=Local避免时区错乱（否则可能全转成 UTC）
sql.Open
不是真的连数据库，db.Ping()
才是第一次校验连接
sql.Open只是初始化连接池配置，返回一个
*sql.DB对象，**并不建立物理连接**。很多新手在这里误以为“打开就通了”，结果后续
Query报错才意识到连不上。 务必在初始化后立刻调用
db.Ping()，捕获连接级错误（如网络不通、认证失败、MySQL 未启动） 连接池参数建议显式设置，避免默认值太激进：
db.SetMaxOpenConns(20)<br>db.SetMaxIdleConns(10)<br>db.SetConnMaxLifetime(60 * time.Second)如果应用短命（如 CLI 工具），记得最后调用
db.Close()；长期服务可忽略（连接池会自动复用和清理）
查询结果扫描时，sql.NullString
和 sql.NullInt64
必须手动处理 NULL
MySQL 字段允许为
NULL，但 Go 基本类型（
string、
int64）不能直接接收。若用普通变量
var name string去
Scan可能为 NULL 的列，会 panic 或静默丢数据。
立即学习“go语言免费学习笔记（深入）”；
正确做法：用sql.NullString、
sql.NullInt64、
sql.NullTime等包装类型 它们都有
Valid字段标识是否非 NULL：
var name sql.NullString<br>err := row.Scan(&name)<br>if err != nil { /* handle */ }<br>if name.Valid {<br> fmt.Println("name =", name.String)<br>} else {<br> fmt.Println("name is NULL")<br>}
别图省事用 *string或
*int64——驱动不支持解引用扫描，会报
sql: Scan error on column index X: unsupported Scan, storing driver.Value type <nil> into type *string</nil>
事务里执行多条语句，必须用 tx.Stmt()
复用预编译语句，别反复 tx.Prepare()
在
*sql.Tx中，如果多次执行相同 SQL（比如批量插入），直接用
tx.Prepare()再
stmt.Exec()是安全的；但如果用
tx.Query()或
tx.Exec()这类快捷方法，底层每次都会新建临时语句，开销大且可能触发 MySQL 的
max_prepared_stmt_count限制。 高频操作应显式调用
tx.Stmt(stmt)获取事务绑定的语句副本（无需重复 Prepare） 示例：
stmt, _ := db.Prepare("INSERT INTO users(name) VALUES(?)")<br>defer stmt.Close()<br><br>tx, _ := db.Begin()<br>txStmt := tx.Stmt(stmt) // 复用，非重新 Prepare<br>txStmt.Exec("alice")<br>txStmt.Exec("bob")<br>tx.Commit()
注意：tx.Stmt()返回的语句只能用于该事务，不能跨事务或混用到普通
*sql.DB
时区、NULL 处理、连接验证、事务内语句复用——这四点漏掉任一，上线后都容易出隐蔽故障。尤其
loc=Local和
parseTime=True，本地开发看着正常，部署到服务器时区不同就突然时间全偏 8 小时。
