Golang监控数据库查询性能方法

最轻量方式是在业务层用 time.Now() + defer 封装 Query/Exec 等调用，避免拼接完整 SQL 防泄密；sqlx 可包装方法加计时，gorm v2+ 应实现 logger.Interface 的 Trace 方法获取真实耗时。

怎么给 database/sql 查询加执行时间日志

Go 标准库的 database/sql 本身不暴露查询耗时，得靠 sql.Driver 层或中间件式包装。最轻量且可控的方式是用 sql.Register 注册一个带计时逻辑的驱动代理，或者更推荐：在业务层统一用 sql.Conn 或 sql.Tx 执行前打点。

实操建议：

• 不要动 sql.Open 返回的 *sql.DB，它只是连接池抽象；真正要监控的是每次 Query、Exec、QueryRow 这些方法调用
• 用 time.Now() + defer 包一层封装函数，比如 logQuery(ctx, "SELECT * FROM users WHERE id = ?", id)
• 避免在日志里拼接完整 SQL（尤其含参数），防止敏感信息泄露；用占位符 + 参数类型/长度代替，如 "SELECT ... WHERE id = ? (int64)"

sqlx 或 gorm 里怎么拿到真实执行耗时

第三方库通常把底层 database/sql 调用包得更深，直接 hook driver.Stmt 不现实。它们一般提供钩子（hook）或可插拔的日志器接口。

实操建议：

• sqlx 没内置耗时统计，但你可以包装 sqlx.DB 的 Queryx 等方法，自己加计时逻辑；注意别漏掉 Get、Select 这些快捷方法
• gorm v2+ 支持 logger.Interface，实现 LogMode 和 Trace 方法即可捕获开始/结束时间；关键是要检查 ctx 是否带 context.WithTimeout，否则耗时可能包含等待上下文超时的时间
• 别信 gorm.Config.Logger 默认输出的 “duration” 字段——那是从 prepare 到 scan 完毕的总时间，不含网络往返和锁等待，和 MySQL 的 Slow_log 对不上

为什么 SHOW PROCESSLIST 看到的 Time 和应用日志差很多

MySQL 的 Time 列表示线程空闲或等待锁的时间，不是 SQL 执行耗时；而 Go 应用日志里测的是从 db.Query 调用到 rows.Close() 或结果解析完成的整个周期，两者根本不在同一维度。

常见错误现象：

• 应用日志显示 50ms，但 PROCESSLIST 显示 Time=0 → 实际查询很快，但 Go 层在做大量 struct scan 或 JSON marshal
• 应用日志 2s，PROCESSLIST Time 却是 1800 → 说明连接被复用，前面某条语句卡住（如没 close rows），当前查询在排队
• 用 SET profiling = 1 查到单条语句 10ms，但 Go 日志记了 300ms → 大概率是连接池阻塞，db.Query 在等空闲连接

监控上线后必须关掉的三个默认行为

本地调试时开着的耗时日志，上线不关会吃 CPU、撑大日志体积、暴露 SQL 结构，甚至拖慢 DB 连接复用效率。

实操建议：

• 禁用所有 fmt.Printf / log.Println 形式的裸日志；改用结构化日志（如 zerolog）并按 level 控制，debug 级才打耗时
• 关闭 gorm 的 Config.LogMode(gorm.LoggerInfo)，生产环境只设 Warn 或 Error
• 别在 http.Handler 中对每个请求都 db.Stats() —— DBStats 是原子读，但高频调用仍会竞争，想看连接池状态应该定时采样，不是 per-request

真正难的不是记录时间，而是区分清楚：这是网络延迟？SQL 执行慢？Go 层反序列化慢？还是连接池配置太小导致排队？每种情况对应的排查路径和修复方式完全不同，别让日志格式统一就误以为原因也统一。