如何在Golang中实现数据库的读写分离中间件 Go语言自定义Proxy

go 的 database/sql 需手动实现读写分离：封装结构体内嵌 *sql.db，重写 query/queryrow 路由从库、exec/begin 等路由主库；事务内所有操作强制走主库；提供 withmaster() 显式指定主库查询；主从连接池独立配置并后台健康检查。

怎么让 Go 的 database/sql 自动路由读写请求

Go 原生 database/sql 没有读写分离能力，必须自己拦截 Query、Exec 等调用做路由判断。不能靠换驱动或改 DSN 实现——那些只是连接参数，不改变行为逻辑。

核心做法是封装一个结构体，内嵌 *sql.DB，重写关键方法：

• Query / QueryRow → 路由到从库（slaveDB）
• Exec / Prepare / Begin → 路由到主库（masterDB）
• 事务内所有操作必须走主库，哪怕调了 Query 也要强制走 masterDB

别试图用 SQL 关键字（如 select）字符串匹配来判断读写——ORM 或拼接语句可能绕过，且 WITH RECURSIVE、INSERT ... RETURNING 这类混合操作会误判。

事务里为什么不能切从库

事务期间任何 Query 调用如果发到从库，大概率查不到刚 INSERT 或 UPDATE 的数据，因为主从延迟存在。这不是 bug，是 mysql/postgresql 复制模型的天然限制。

立即学习“go语言免费学习笔记（深入）”；

实现时得在 Begin 返回的 *sql.Tx 上再包一层，确保它的 Query、Exec 全部透传给主库连接：

type rwTx struct {     *sql.Tx     masterDB *sql.DB // 只存引用，不重复 open }

注意：不能把 *sql.Tx 当普通接口用，它内部持有了连接状态；直接转发调用即可，别尝试“跨库提交”。

如何识别哪些查询真该走从库

不是所有 SELECT 都安全走从库。常见陷阱包括：

• SELECT for UPDATE —— 必须主库，否则锁失效
• 刚执行过 INSERT 就查同表最新记录（比如查自增 ID）——从库延迟导致查不到
• 使用了 LAST_INSERT_ID()、@@IDENTITY 这类会话变量函数

稳妥做法是：默认读走从库，但提供显式 API 强制走主库，比如加个 WithMaster() 方法：

db.WithMaster().Query("SELECT ... FOR UPDATE")

比自动解析 SQL 更可靠，也更易 debug——日志里能清楚看到谁主动切了主库。

连接池和健康检查怎么不拖慢请求

主从库连接池要独立配置：SetMaxOpenConns 和 SetMaxIdleConns 得分别调，从库通常可设更大值；但别共用同一个 *sql.DB 实例，否则 Close() 会误关掉另一端。

健康检查不能同步阻塞请求。建议：

• 后台 goroutine 定期 ping 主从库（比如每 10 秒）
• 失败时标记对应实例为 “unhealthy”，后续路由跳过它
• 恢复后自动重新加入，不需重启服务

特别注意：MySQL 的 ping 默认不校验权限，得用 db.Query("SELECT 1") 才真正走查询路径；PostgreSQL 则推荐用 db.Query("SELECT 1") 或 pgx.Ping（如果用 pgx）。

读写分离中间件最难的不是路由逻辑，而是怎么让开发者感知不到主从差异，又能在出问题时快速定位到是哪个库挂了、延迟多少、有没有被误切。监控指标和日志上下文比代码本身更重要。