应先明确需求是连接池管理、ORM抽象还是纯SQL控制权再选型；database/sql与mysql驱动必须配合使用；推荐DSN用URL格式并正确配置parseTime和loc；sqlx适用于结构体映射等场景；ORM性能略低但提升开发确定性；需注意DNS解析与时区问题。
Go 连 MySQL 不该从 database/sql + mysql 驱动开始写起，而应先确认你真正需要的是连接池管理、还是 ORM 抽象、或是纯 SQL 控制权 —— 三者目标不同，选型逻辑完全不同。
为什么 database/sql + go-sql-driver/mysql 是默认起点
Go 官方 database/sql 是接口层，不实现具体数据库协议；go-sql-driver/mysql（常被简称为 mysql 驱动）才是实际完成 TCP 握手、认证、包解析的实现。二者必须配合使用，缺一不可。
常见错误现象：
- 只导入
"database/sql"却没导入驱动，运行时报"sql: unknown driver 'mysql' for 'mysql' - 导入了驱动但没用下划线别名（如
_ "github.com/go-sql-driver/mysql"），导致驱动未注册 - DSN 中写错参数名，比如把
parseTime=true写成parsetime=true，时间字段变成零值
实操建议：
- DSN 格式统一用 URL 形式更安全：
"user:pass@tcp(127.0.0.1:3306)/dbname?charset=utf8mb4&parseTime=true&loc=Local" -
parseTime=true必须配loc=Local或loc=UTC，否则time.Time扫描失败 - 连接池参数在
*sql.DB上设置，不是 DSN 里：db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10)
什么时候该换 sqlx 而不是硬啃 database/sql
当你反复写 rows.Scan(&a, &b, &c)，字段一多就容易错位、漏变量、类型不匹配 —— 这是 sqlx 存在的核心理由：它兼容 database/sql 接口，但支持结构体自动映射。
使用场景：
- 查询结果需直接转为 struct（如
type User struct { ID int `db:"id"` Name string `db:"name"` }） - 批量插入时想复用命名参数（
INSERT INTO users (name, age) VALUES (:name, :age)） - 不想手动维护
Scan参数顺序，又不愿引入完整 ORM
注意点：
-
sqlx不是 ORM，不处理关联、迁移、钩子；它只是database/sql的“语法糖增强版” - 结构体 tag 默认是
db，不是json或gorm；混用时要显式指定 - 事务操作仍用原生
db.Begin()，sqlx只提供tx.NamedExec等便利方法
ORM（gorm / ent）真比裸连快？
不。几乎所有 ORM 在单条简单查询上都比原生 QueryRow 慢 10%–30%，因为多了反射、SQL 构建、结果映射三层开销。性能差异在高并发、小查询场景下会被放大。
但 ORM 的价值不在速度，而在开发确定性：
-
gorm自动处理预编译语句缓存、空值兼容（sql.NullString→*string）、软删除、时间字段自动填充 -
ent是代码生成型 ORM，所有操作在编译期校验，没有运行时 panic 风险，适合中大型服务 - 两者都内置连接池管理，但默认配置偏保守（如
gorm默认MaxIdleConns=1），上线前必须重设
容易踩的坑：
-
gorm.Open(mysql.Open(dsn), &gorm.Config{...})返回的是*gorm.DB，不是*sql.DB；要取底层连接需调db.Statement.ConnPool.(*sql.DB) -
ent的Client对象本身不带连接池，它依赖传入的*sql.DB，池参数得在外层设好再传进去
连接 MySQL 最容易被忽略的点，其实是 DNS 解析和时区传递 —— 容器内用 service name 连接时，Kubernetes 的 DNS 缓存可能让连接卡在 lookup mysql-service 阶段；而 loc=Local 在容器没挂载宿主机 /etc/localtime 时会退成 UTC，导致时间字段全偏移 8 小时。这些都不报错，只默默出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
