先从我自己的实际情况说起。我在写一个内部数据同步工具时需要从线上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网络类型一般取tcptcpAddrMySQL地址和端口127.0.0.1:3306User用户名按环境调整Password密码按环境调整DBName连接的默认数据库按环境调整Charset连接字符集utf8mb4Timeout连接超时时间5s或10s视网络质量调整ReadTimeout读超时防止一条SQL卡死建议显式设置WriteTimeout写超时建议显式设置TLSConfig如果走SSL连接需要暴露TLS非必填内网可关连接超时这个配置很多人会忽略觉得本地连接快就不需要超时。但线上环境千变万化一旦MySQL地址被防火墙挡住没有Timeout的连接会一直卡在底层的TCP建立阶段非常难排查。我在第一次压测时就遇到过连接卡了将近两分钟才报错后来给所有连接对象都加上了5秒的Timeout排查问题也方便多了。2.3 字符集和时区问题不是小事是拦截性问题先说字符集。MySQL的utf8和utf8mb4是两个不同的东西utf8最多支持3个字节编码存不了emojiutf8mb4才是完整的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也不能一直不Closego-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和ValuesExecute返回的不是一个简单的行集合而是一个*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()方法返回trueValue()返回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 ) ENGINEInnoDBCSV里面每一行就是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/sql7.1 我的选型判断标准这套实战做下来我发现一个问题go-mysql确实强大但并不适合所有场景。很多读者可能只是需要一个普通的数据库访问层那我的建议是很明确的别因为看到了这篇博文就去换驱动。选型标准我总结成了一张表场景推荐方案常规Web后端CRUDdatabase/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()确保通路上没问题再往后操作。这个检查成本极低但在环境配置错误时能第一时间定位省下来的排查时间远比付出的多。
