先从我自己的实际情况说起。我在写一个内部数据同步工具时，需要从线上MySQL读大量业务数据，再写入另一个MySQL实例做校验比对。第一反应是用标准库的database/sql加驱动，结果写到一半发现两个问题：一是结果集的字段类型信息被框架抽象掉了一层，我拿不到足够原始的协议细节；二是后续模块要消费binlog里的增量事件，走标准库这条路根本接不进去。于是我把整个数据操作层换成了go-mysql，从查询到数据输入全部重写。这一趟折腾下来，踩了不少坑，也沉淀了一套可以直接抄作业的写法。
这篇文章不是讲go-mysql的API手册，而是从一次真实的数据查询和数据输入实战出发，把连接建立、结果集解析、批量写入、事务控制、并发处理和选型边界讲清楚。适合正在做MySQL工具、数据迁移、中间件开发，或者单纯想在Go项目里更精确地控制MySQL协议的读者参考。
1. go-mysql的真身：它不是一个普通驱动，而是一套MySQL协议工具集
1.1 先看清楚它包含哪几块
很多刚接触go-mysql的人会把它当成一个普通的MySQL驱动来用，这是对它最大的误解。go-mysql的仓库地址是github.com/go-mysql-org/go-mysql，早期代码还在github.com/siddontang/go-mysql下面，后来迁移到了go-mysql-org组织。它本质上是一套用Go语言实现的MySQL协议栈，下面挂了好几个子包，各管一摊：
- mysql包：最底层，实现了MySQL wire protocol的数据包解析、字段类型、结果集结构等核心定义。
- client包：一个完整的MySQL客户端，可以直接连库、执行SQL、遍历结果集，不带任何框架层封装。
- replication包：实现了MySQL主从复制协议，可以伪装成slave接收binlog事件。
- canal包：在replication之上做了更高层的binlog订阅和行数据解析，有点类似Java生态里Canal的味道。
所以当你引入go-mysql的时候，你拿到的不是"又一个database/sql驱动"，而是一整套可以直达协议深处的工具箱。查询和数据输入只是其中client包的基本功，真正让它与众不同的，是后面几个包对binlog的消费能力。这个定位决定了我后续所有代码组织的思路：查询和写入只是敲门砖，后面接增量同步才是这套库的主场。
1.2 我为什么在这个场景里选它而不是标准库
这里先把话说透：如果你的项目就是一个普通Web后端，CRUD为主，事务嵌套不算太复杂，那我劝你还是老老实实用database/sql加go-sql-driver/mysql，别折腾。go-mysql的优势不在日常增删改查上，而在下面这些地方：
- 你需要把结果集的字段名、类型、原始二进制值完整拿到手，而不是被Scan进一堆强类型变量。
- 你需要自己控制连接的打开、关闭、心跳、重连，而不是交给连接池的默认策略。
- 你要做数据迁移、binlog监听、协议层面的嗅探或者在线DDL工具，标准库驱动根本给不了这种细粒度。
- 你想在同一个项目里做到"普通查询用标准库，协议层操作用go-mysql"的混合形态。
在我那个内部同步工具里，查询和数据输入只是前半段，后半段要订阅binlog增量，所以选go-mysql几乎是没有退路的选择。但即便是只用它的client包做查询和写入，连接方式和结果集处理也跟标准库有很大差别，这些差别恰恰是后面所有坑的来源。
2. 连接建立：光标配置比你以为的多，字符集和时区必须提前定好
2.1 一段能跑起来的最简连接代码
go-mysql的client包连接方式很简单，核心方法是client.Connect，传入地址、用户、密码、库名即可。我第一次跑通时写的代码长这样：
package main import ( "log" "github.com/go-mysql-org/go-mysql/client" ) func main() { conn, err := client.Connect("127.0.0.1:3306", "root", "123456", "demo") if err != nil { log.Fatal(err) } defer conn.Close() log.Println("connected:", conn.String()) }就这么几行，一个能用的连接就建立起来了。但我很快发现，如果不加额外配置，后面写中文、存时间、处理特殊字符都会有各种别扭的问题。所以实际项目中，我会在Connect的时候多挂一个配置函数，把字符集显式设置好：
conn, err := client.Connect( "127.0.0.1:3306", "root", "123456", "demo", func(c *client.Conn) { c.SetCharset("utf8mb4") }, ) if err != nil { log.Fatal(err) }SetCharset的作用是让后续所有SQL交互都按指定字符集编码，这里直接上utf8mb4，因为utf8在MySQL里并不是真正的utf8，它存不下emoji和一些特殊字符。这个教训我等下还会专门讲，因为踩过太多次了。
2.2 连接配置项逐项拆解
如果你需要的配置更多，可以构造一个完整的客户端配置对象再连接。go-mysql不同版本对配置对象的命名略有不同，但核心字段是稳定的，我整理了一张表方便对照：
| 配置项 | 作用 | 建议值 |
|---|---|---|
| Net | 网络类型，一般取tcp | tcp |
| Addr | MySQL地址和端口 | 127.0.0.1:3306 |
| User | 用户名 | 按环境调整 |
| Password | 密码 | 按环境调整 |
| DBName | 连接的默认数据库 | 按环境调整 |
| Charset | 连接字符集 | utf8mb4 |
| Timeout | 连接超时时间 | 5s或10s，视网络质量调整 |
| ReadTimeout | 读超时，防止一条SQL卡死 | 建议显式设置 |
| WriteTimeout | 写超时 | 建议显式设置 |
| TLSConfig | 如果走SSL连接，需要暴露TLS | 非必填，内网可关 |
连接超时这个配置很多人会忽略，觉得本地连接快就不需要超时。但线上环境千变万化，一旦MySQL地址被防火墙挡住，没有Timeout的连接会一直卡在底层的TCP建立阶段，非常难排查。我在第一次压测时就遇到过连接卡了将近两分钟才报错，后来给所有连接对象都加上了5秒的Timeout，排查问题也方便多了。
2.3 字符集和时区问题：不是小事，是拦截性问题
先说字符集。MySQL的utf8和utf8mb4是两个不同的东西，utf8最多支持3个字节编码，存不了emoji；utf8mb4才是完整的UTF-8。如果你在连接时没设置字符集，然后用字符串SQL插入一条带emoji的数据，大概率会得到"incorrect string value"的报错。更隐蔽的是，如果MySQL服务端默认字符集是latin1或者gbk，你甚至会在不报错的情况下存进一堆乱码，数据进去再查出来已经不是原来的内容了。
所以我的建议非常直接：任何新建的go-mysql连接，只要字段里可能有中文、emoji、生僻字，连接后第一件事就是SetCharset("utf8mb4")。这句话写在你代码的公共初始化模块里，别写在某一条业务的中间，因为很容易被后面的人漏掉。
再谈时区。go-mysql的client包在执行SQL时，如果要传time.Time对象作为参数，最终会序列化成MySQL的日期时间格式。这个过程跟连接配置里的时区有关，如果你不显式设置，会用操作系统本地时区，而MySQL服务端通常有自己的time_zone配置，两边不一致就会出现插入的时间到库里被偏移了几个小时。这个问题在同步工具里尤其致命，因为时间字段一旦错位，后面做数据对比的时候怎么都对不上。
我现在的做法是：在连接配置里明确指定时区，同时让MySQL连接也走同一个时区基准。这样time.Time传到库里保持"同一个时间点"，而不是"同一个时钟读数"。生产环境的服务器时区往往千奇百怪，不要指望环境默认值，自己写死最安全。
2.4 连接生命周期：别盲目Close，也不能一直不Close
go-mysql的client连接不像database/sql那样有连接池托管，你new出来的Conn对象要用多久、用完怎么回收，都得自己管理。很多人写完代码习惯性defer conn.Close()，对于一次性的脚本没问题；但如果你的程序是个长驻服务，每条SQL都重新Connect再Close，连接开销就会非常扎眼。
更麻烦的是，go-mysql的一个Conn绑定的是一条真实的MySQL连接，它的状态不是并发安全的。你要是图省事，把同一个conn放在多个goroutine里同时Execute，轻则结果串数据，重则直接把协议流程搞乱，连接直接断掉。正确的做法是：长驻服务里维护一组连接，每个goroutine在某个时间段内独占一条连接，用完归还；或者干脆做一个简单的自旋锁来保护单连接。
还要考虑MySQL服务端的wait_timeout和interactive_timeout。如果一条连接空闲太久，服务端会主动断开，go-mysql客户端此时还在继续Execute，就会碰到"bad connection"之类的错误。我通常会给长驻模块加一个定时Ping或者定时执行SELECT 1的重保活逻辑，防止连接被服务端回收后还在继续用。
3. 查询实操：Execute返回的Result结构不拆开你看不懂
3.1 基本查询语法和参数绑定
go-mysql的Execute方法支持参数占位符，参数用问号表示，和database/sql的写法很像。比如要查一批用户：
result, err := conn.Execute(`SELECT id, name, score, created_at FROM users WHERE status = ? AND created_at >= ?`, 1, startTime) if err != nil { log.Fatal(err) }这里有一个容易被忽略的地方：go-mysql会把你传入的参数按它自己的一套规则做类型映射和编码，最后在MySQL协议层以二进制形式传输。也就是说，参数并不会以纯文本SQL的方式拼接进语句，避免了常见的SQL注入问题。这一点和直接拼字符串的本质区别很大，也让我在使用时放心了不少。
参数类型映射上，我会特别注意以下几点：
- 传nil的时候，最终会变成SQL里的NULL，这个行为是直觉的，但经常有人忘记处理。
- 传int/int64会走有符号整数类型；传uint64会走无符号类型，如果值超过有符号上限，必须用uint64方式传。
- time.Time会序列化成日期时间字符串，但前缀受连接时区的配置影响。
- []byte类型直接作为二进制串传输，适合BLOB字段。
- string类型按连接字符集编码，所以前面说的utf8mb4在这里发挥作用。
3.2 结果集的关键结构：Fields和Values
Execute返回的不是一个简单的行集合，而是一个*mysql.Result结构。这个结构里最有价值的部分是Resultset，打开它你就能看到字段定义和具体数据：
rs := result.Resultset if rs == nil { log.Println("no resultset") return } for i, row := range rs.Values { log.Printf("row %d:", i) for j, val := range row { log.Printf(" field=%s value=%v", rs.FieldNames[j], val.Value()) } }rs.Values是一个二维数组，每一行对应一条记录，每一个元素是一个mysql.FieldValue。FieldValue不是普普通通的interface{}，它封装了类型、原始字节和转换方法，你可以调AsString、AsInt64、AsUint64、AsFloat64等方法拿到想要的类型。我一开始很纳闷为什么不直接给interface{}，后来才明白：MySQL返回的二进制结果集里，每个字段都是字节序列，直接把字节裸转成interface{}容易出现编码和类型转换的歧义，而FieldValue这种封装让调用者自己决定怎么解释，反而更灵活。
实际项目中，我习惯把行转换为一个map[string]interface{}导出，这样业务代码用起来语义更清楚：
func rowsToMaps(rs *mysql.Resultset) []map[string]interface{} { if rs == nil { return nil } rows := make([]map[string]interface{}, 0, len(rs.Values)) for _, row := range rs.Values { m := make(map[string]interface{}, len(rs.Fields)) for j, val := range row { if val.IsNull() { m[rs.FieldNames[j]] = nil continue } switch val.Type() { case mysql.MYSQL_TYPE_LONG, mysql.MYSQL_TYPE_LONGLONG: m[rs.FieldNames[j]] = val.AsInt64() case mysql.MYSQL_TYPE_FLOAT, mysql.MYSQL_TYPE_DOUBLE, mysql.MYSQL_TYPE_NEWDECIMAL: m[rs.FieldNames[j]] = val.AsFloat64() default: m[rs.FieldNames[j]] = val.AsString() } } rows = append(rows, m) } return rows }这段代码里有一个关键点：mysql.FieldValue.Type()返回的字段类型是MySQL协议层的类型码，和MySQL存储引擎里的类型并不是完全一一对应关系。比如DATETIME、TIMESTAMP、VARCHAR、TEXT这些在协议层都归为MYSQL_TYPE_STRING或MYSQL_TYPE_DATETIME，你按自己的需求决定是取字符串还是再单独做时间解析。我通常选择取字符串，然后在业务层用统一的time.Parse去解析，避免多个时区逻辑散落在各个地方。
3.3 空结果和NULL值的边界处理
这里必须单独强调一下空结果的陷阱。执行一条SELECT，如果一行数据都没有，result.Resultset并不会是nil，它依然有完整的FieldNames，只是Values的长度为0。如果你在代码里依赖"Resultset == nil判断空结果"，那就会产生误导。
正确判断空结果的方法是len(rs.Values) == 0。另外，MySQL里的NULL在go-mysql中对应FieldValue的IsNull()方法返回true，Value()返回nil。我踩过的坑是：用AsString去处理NULL字段，会得到一个空字符串，看起来像数据缺失但其实是NULL，如果你不做区分，等会儿查出来的数据和源数据做对比时会平白多出一堆差异。
我习惯在所有解析结果集的地方统一约定好：凡是IsNull()为true，一律在map里放nil，不做任何类型转换；凡是非NULL再走类型分支。这个约定放到模块里之后，数据对比的错误率马上下来了。
3.4 大数据量查询：别指望一次Execute拿全量
go-mysql的client包执行SELECT时，会把服务端返回的结果集完整读取到内存中，也就是说result.Resultset.Values里会一次性装着所有行。如果你的查询命中了几百万行，且单行有大字段，内存会直接被打爆。
我处理这种场景的办法是分页或游标。比如按主键ID分段查询，每次查一万条，记录当前最大ID，下一次从最大ID之后继续查。这种方法对任何版本的MySQL都通用，只要表有主键，操作简单而且可控。
const batchSize = 10000 lastID := int64(0) for { result, err := conn.Execute( `SELECT id, name, score FROM users WHERE id > ? ORDER BY id LIMIT ?`, lastID, batchSize, ) if err != nil { return err } rows := rowsToMaps(result.Resultset) if len(rows) == 0 { break } processRows(rows) lastID = rows[len(rows)-1]["id"].(int64) }这段代码的核心思路是让每次查询都只拉一小批数据，处理完再拉下一批。注意这里的LIMIT是固定的，但配合WHERE id > 游标值可以保证不会漏数据，也不会和新增数据冲突。
4. 数据输入实战：INSERT、批量写入与类型映射
4.1 单条INSERT的三个关注点
数据输入的核心动作就是INSERT。go-mysql执行INSERT和SELECT一样，都用Execute方法，参数同样走占位符。我写第一版脚本时，最关心的三个点是：插入是否成功、影响了几行、新插入的ID是什么。
result, err := conn.Execute( `INSERT INTO users (id, name, score, created_at) VALUES (?, ?, ?, ?)`, 1001, "张三", 88, time.Now(), ) if err != nil { log.Fatalf("insert failed: %v", err) } log.Printf("affected rows: %d", result.AffectedRows) insertID := result.InsertId // 注意某些版本字段名为InsertId，而非LastInsertId log.Printf("last insert id: %d", insertID)这里提醒一句：go-mysql的Result结构在不同版本里，字段命名有过变化。你自己用的时候最好go doc一下，确认是InsertId还是LastInsertId，别照抄我的代码然后编译报错就懵了。核心语义是一样的：当INSERT操作有自增主键或用了AUTO_INCREMENT时，InsertId就是新的主键值。
AffectedRows这个值也值得多看两眼。在插入时，如果插入的数据和原有数据主键冲突且不是真正的插入，而是走了INSERT ... ON DUPLICATE KEY UPDATE的更新路径，AffectedRows可能会有1和2两种结果。这个别被它吓到，MySQL官方文档里就明确说过这个语义，不是你代码的问题。
4.2 批量写入的正确姿势：一次网络往返插入多行
单条INSERT的问题在于网络开销。你每执行一条INSERT，应用层要和MySQL进行一次完整的交互，如果数据量是几万条，就有几万次网络往返，全部卡在IO上。我第一版脚本就是这么写的，往表里灌五万条数据用了差不多五六分钟，明显不对劲。
改成批量写入之后，问题立刻缓解。批量写入的做法是构造一条多值INSERT语句，把多条记录拼接在一次Execute中执行：
func batchInsert(conn *client.Conn, rows [][]interface{}) error { if len(rows) == 0 { return nil } const batchSize = 1000 for start := 0; start < len(rows); start += batchSize { end := start + batchSize if end > len(rows) { end = len(rows) } batch := rows[start:end] var sb strings.Builder sb.WriteString("INSERT INTO users (id, name, score, created_at) VALUES ") placeholders := make([]string, 0, len(batch)) args := make([]interface{}, 0, len(batch)*4) for _, row := range batch { placeholders = append(placeholders, "(?, ?, ?, ?)") args = append(args, row[0], row[1], row[2], row[3]) } sb.WriteString(strings.Join(placeholders, ",")) _, err := conn.Execute(sb.String(), args...) if err != nil { return err } } return nil }这里每一批拆成1000行，每批一条INSERT语句，总共的网络往返是数据量除以1000。五万条数据，50次交互就结束了，耗时从几分钟降到几秒，效果立竿见影。
批量大小的上限不是越大越好。我实测过，1000条一批对于普通行宽（几个字段、几十字节）非常舒服；如果行里有很长的TEXT字段，半兆字节一行，那一批几十条可能就比1000条短字段更合适。核心原则是让单条SQL的数据包大小不要超过MySQL的max_allowed_packet限制，同时让客户端内存占用可控。我习惯用"每个批次的总字节数不超过8MB"作为兜底，具体看字段情况微调。
4.3 批量写入和事务配合：要么都成功，要么都失败
批量写入如果没有事务保护，最容易出现的问题是：插到一半报错了，前面几百条已经提交进去了，后面几百条没进去，数据处于残缺状态。同步工具一旦出现这种半截数据，排查成本非常高，因为你根本不知道是数据源问题还是写入中断问题。
所以我在批量导入模块里一定会裹上事务，把一批甚至整个批量任务放进一个事务窗口：
_, err := conn.Execute("BEGIN") if err != nil { return err } defer func() { // 保证出错时一定回滚，成功时再提交 if err != nil { conn.Execute("ROLLBACK") } }() if err = batchInsert(conn, rows); err != nil { return err } _, err = conn.Execute("COMMIT") if err != nil { return err } return nil这段代码的逻辑是：先BEGIN，然后执行所有批量INSERT，全部成功才COMMIT，任何一步出错就ROLLBACK。这样整个批次要么全部落库，要么什么都不留。注意defer里判断的是命名返回值err，如果你用的是非命名返回值，需要在函数签名里写成带名字的错误变量，否则defer读不到最新错误。我在写过一次无命名返回值版本后，差点被这个"看起来回滚了其实没回滚"的问题坑惨。
4.4 时间、字符串、二进制字段的输入映射
输入数据时的类型映射比查询稍微简单，因为是Go的值往MySQL协议里塞，主动权在自己手里。但我也踩过一个有趣的坑：把一个Go字符串直接传给DATETIME类型的字段，MySQL协议层会按字符串处理字段值，服务端再做类型解析，如果字符串格式稍微不符合MySQL默认的日期格式，就会插入失败报"incorrect datetime value"。
更稳妥的做法是传time.Time对象，go-mysql会在协议层直接编码成MySQL认可的二进制日期格式。但前提是连接时区得一致，这在前面已经讲过了。
再提一个二进制字段的坑。如果你有BLOB或者VARBINARY字段，传入值必须用[]byte类型。有人图省事直接传string，看着好像也能用，但字符串会走字符集编码，如果字符集是utf8mb4，而你的二进制数据本来就不是合法的UTF-8序列，那么编码过程会产生错误或数据损坏。所以二进制数据一定传[]byte，别传string。
字符串字段我需要特别提醒转义问题。用占位符传参不会有转义问题，但如果你出于某种原因手拼SQL字符串，那么字符串里的单引号必须转义成双引号。go-myql的Execute用占位符可以完全避开这个坑，我见过不少人还在手拼字符串，看着危险又没必要。
5. 写库的一致性与并发：没有database/sql的Tx，自己管好连接状态
5.1 先从设计上理解go-mysql客户端的事务模型
database/sql有明确的Tx对象，Begin之后在Tx上做查询和提交，连接的状态由标准库帮你管理。go-mysql的client没有这个抽象，Execute是直接作用在一个Conn上的，而事务本质上是"同一个连接上的会话状态"。你要开启事务，就手动在这个连接上执行BEGIN；要提交，就执行COMMIT；要回滚，就执行ROLLBACK。
这就引出一个关键约束：事务的所有操作必须发生在同一条连接上。如果你中途换了一条连接，新的连接并没有BEGIN的状态，后面的COMMIT自然也是空的。所以任何封装事务逻辑的函数，都要明确接收一个Conn参数并始终用它执行，而不是内部自己新建连接。
我在代码组织上通常会写一个统一的WithTx函数，把事务生命周期封装掉：
func WithTx(conn *client.Conn, fn func(c *client.Conn) error) error { if _, err := conn.Execute("BEGIN"); err != nil { return err } committed := false defer func() { if !committed { conn.Execute("ROLLBACK") } }() if err := fn(conn); err != nil { return err } if _, err := conn.Execute("COMMIT"); err != nil { return err } committed = true return nil }这个函数的逻辑很直观：进入事务后执行传入的回调，回调里做的所有写操作都在同一条连接上；只要其中任何一步出错，defer里的ROLLBACK就会兜底回滚。注意COMMIT之后要把committed置为true，否则COMMIT成功后defer还会执行一次ROLLBACK，白白产生一次无结果的交互。
5.2 并发写入最容易翻车的点：共享连接
go-mysql的Conn不是并发安全的，这一点我再强调一遍。很多从database/sql切换过来的人，因为习惯了连接池自动管理，容易下意识地把一个conn传给多个goroutine同时Execute，结果立刻就崩。崩溃的原因也很好理解：底层TCP连接上同时交织着多条命令的请求和响应，数据包对不上了，协议直接乱掉。
我自己常用的几个并发模式如下：
- 单连接串行化：用一个互斥锁保护conn，所有写入请求排队执行。简单可靠，适合写入QPS不高的场景。
- 连接池化：维护一组Conn，每个任务分配一个可用Conn，用完归还。适合并发读写同时存在的场景，但要注意每个连接的使用时长和归还后的状态清理。
- 按goroutine绑连接：每个工作goroutine自己建一条Conn，任务结束后关闭。适合一次性批量任务，互不干扰，代价是连接数可能很多。
我最后推荐的是第二种。手写连接池不复杂，核心就是用一个channel存空闲连接，每次申请时从channel取，耗时长了就新建，用完了放回channel。这样既保证了并发能力，又避免了每条连接被多协程同时使用的风险。要注意的是归还前一定要确定连接处于"干净状态"：比如刚才是不是开过事务没提交，是不是出现过错误导致协议半包。出现坏连接时直接关闭丢弃，不要放回池子。
5.3 错误识别与重试策略
写库过程中一定会遇到错误，但不是所有错误都值得重试。我把常见的错误分为几类：
| 错误类型 | 典型场景 | 处理策略 |
|---|---|---|
| 连接被断开 | 网络抖动、服务端重启 | 可以重试，但要先重建连接 |
| 锁等待超时 | 并发写同一行、长事务阻塞 | 可以小延迟后重试，但多次失败要报警 |
| 语法错误 | SQL方言不兼容、字段写错 | 不重试，直接暴露给开发者 |
| 数据超限 | 数字溢出、字符串超长 | 不重试，属于数据问题 |
| 唯一键冲突 | 数据重复 | 看业务：跳过或走更新逻辑 |
重试最重要的原则是：不是所有错误都能重试。如果每次都是唯一键冲突，你重试一百遍也还是冲突，反而白白浪费资源。我写了个简单的重试工具，只针对连接断开和锁等待超时这两类错误重试，重试次数控制在三次以内，每次重试前休眠递增的时间（比如100ms、300ms、900ms）。超过三次还没成功就抛出去交给上层告警，而不是闷头重试到底。
6. 实测过程：一个数据导入脚本的完整演进
6.1 需求是什么
为了验证前面讲的这些点，我做了一个模拟导入场景：把一份五万行的CSV文件导入MySQL的临时表，导入完成后做一次全量查询校验，统计成功行数和失败行数。这个场景几乎包含了查询和数据输入的全部要素：读文件、解析CSV、构造INSERT、批量写入、事务保护、最终查询校验。
表结构很简单：
CREATE TABLE IF NOT EXISTS user_import ( id INT PRIMARY KEY, name VARCHAR(64), score INT, created_at DATETIME ) ENGINE=InnoDBCSV里面每一行就是id、name、score、created_at四个字段。
6.2 第一版慢在哪
第一版我图简单，拿到CSV一行就往数据库里INSERT一行，还是逐条Execute。实测结果非常难看：五万行数据跑完用了将近六分钟。部分时间花在每条INSERT的网络往返上，还有一部分花在默认自动提交的两次协议交互上。
这一版跑完我连校验查询都没心情做，先记下耗时，然后开始改。修改方向就是前面提到的批量INSERT和事务包裹，另外把created_at解析为time.Time再传入，保证类型语义统一。
6.3 改进后的完整流程
改进后的核心流程是：一次性读完整份CSV到内存（五万行在这个量级完全没问题），按照每批1000行切分，每批执行一次批量INSERT，所有批次放在同一个事务里。导入结束后执行SELECT COUNT(*)和采样校验。
核心代码结构如下：
package main import ( "encoding/csv" "io" "log" "os" "strconv" "time" "github.com/go-mysql-org/go-mysql/client" ) func main() { conn, err := client.Connect("127.0.0.1:3306", "root", "123456", "demo", func(c *client.Conn) { c.SetCharset("utf8mb4") }) if err != nil { log.Fatal(err) } defer conn.Close() rows, err := readCSV("data.csv") if err != nil { log.Fatal(err) } start := time.Now() if err := importWithTx(conn, rows); err != nil { log.Fatal(err) } log.Printf("import done, elapsed=%s", time.Since(start)) result, err := conn.Execute("SELECT COUNT(*) FROM user_import") if err != nil { log.Fatal(err) } count := result.Resultset.Values[0][0].AsInt64() log.Printf("total rows in table: %d", count) } func readCSV(path string) ([][]interface{}, error) { f, err := os.Open(path) if err != nil { return nil, err } defer f.Close() r := csv.NewReader(f) rows := make([][]interface{}, 0, 50000) for { record, err := r.Read() if err == io.EOF { break } if err != nil { return nil, err } id, _ := strconv.ParseInt(record[0], 10, 64) score, _ := strconv.ParseInt(record[2], 10, 64) createdAt, _ := time.Parse("2006-01-02 15:04:05", record[3]) rows = append(rows, []interface{}{id, record[1], score, createdAt}) } return rows, nil }批量插入和事务封装的函数沿用前面章节写过的逻辑，这里不再重复。整段代码跑完后，五万行数据的导入时间从将近六分钟降到了四秒出头，事务和批量写入的效果非常明显。
6.4 从这轮实测里总结出的硬经验
这个导入脚本虽然简单，但它把所有我讲过的坑都走了一遍。做完之后我给自己列了三条硬经验：
第一，批量写入一定要配合事务使用。如果只在代码里拼多值INSERT而不开事务，每批之间依然是自动提交模式，中途断电或报错照样留下半批数据。
第二，CSV解析出的字段要明确各自的最终类型。尤其数值型和日期型，不要图省事全给string，你插入时好像很顺利，后面查询比对时不同类型之间互相转来转去，迟早出bug。
第三，脚本跑完一定要做一次全量校验查询。不只是SELECT COUNT(*)看数量对不对，最好抽样几行和源CSV里的值逐字对比。数据同步工具最怕的就是数量对得上，但某个字段错位了或者被截断了你完全没察觉。
7. 什么时候该用go-mysql，什么时候换回database/sql
7.1 我的选型判断标准
这套实战做下来，我发现一个问题：go-mysql确实强大，但并不适合所有场景。很多读者可能只是需要一个普通的数据库访问层，那我的建议是很明确的：别因为看到了这篇博文就去换驱动。选型标准我总结成了一张表：
| 场景 | 推荐方案 |
|---|---|
| 常规Web后端CRUD | database/sql + go-sql-driver/mysql |
| 复杂的ORM查询和模型绑定 | 还ai用gorm或其他ORM方案，没必要动协议层 |
| 数据迁移、ETL、同步工具 | go-mysql的client包 |
| binlog订阅、主从复制相关 | go-mysql的replication/canal包 |
| 自己封装MySQL协议的工具 | go-mysql的mysql包做底层基础 |
核心判断是：如果你只需要"把数据存进去、查出来"，database/sql那套抽象已经绰绰有余；如果你需要"精确控制协议细节、直接消费binlog或者做底层基础设施"，go-mysql才有不可替代的价值。
7.2 同一个项目里混用也可以
还有一类项目的形态是：主业务用标准库，但某个模块需要binlog增量，或者需要拿protocol层的结果集做特殊处理。这种时候完全可以在同一个程序里同时用database/sql和go-mysql，它们各管各的连接，互不影响。
我唯一会注意的边界是：不要在同一个事务里跨两套连接操作。标准库事务的提交和回滚只对它自己管理的连接有意义，go-mysql的事务只对它自己的Conn有意义，两种连接不能混在一个事务里。如果业务上确实需要跨模块事务，我会把其中一边的操作收敛到另一边去，避免出现"看起来都执行了，但没有统一提交"的局面。
7.3 个人体会
整套go-mysql查询和数据输入实战跑完之后，我最深的感觉是：工具没有绝对的好坏，只有跟场景匹配不匹配。go-mysql让我在协议层有了很高的自由度，但也把连接管理、结果集解析、事务控制这些平时被标准库藏起来的复杂性全部暴露了出来。别小看这些"暴露出来的活"，它们才是数据库工具开发真正的门槛。跑通查询和写入只是入场券，把连接资源、错误重试、字符集时区这些"看不见"的地方管好，才是后续做增量同步这类高级功能能站得住脚的基础。
最后分享一个我自己的小习惯：在任何涉及MySQL协议的项目里，连接建立后我先执行一次SELECT VERSION()，确保通路上没问题，再往后操作。这个检查成本极低，但在环境配置错误时能第一时间定位，省下来的排查时间远比付出的多。
