核心手段是用 sql.Register 注册带计时的包装驱动
想在Go里监控SQL执行时间，绕不开一个核心问题：标准库的 database/sql 本身并没有提供执行耗时的钩子。这意味着，你必须在驱动层动手脚。直接修改原生驱动（比如 github.com/lib/pq）显然不是个好主意，更优雅的做法是使用包装器模式——注册一个新的驱动名，比如叫 pg_timed，然后应用里就用这个名字来打开数据库连接。
这里的关键在于，你写的这个包装器，必须完整实现 driver.Driver 接口。更重要的是，在它的 Open 方法返回的 driver.Conn 里，得把所有执行方法，比如 Exec、Query，以及它们的 Context 版本，都包裹上一层计时逻辑。
- 计时要精确：直接用
time.Now()记录开始时间，结束时用.Sub()计算差值。别看time.Since()用起来方便，它内部多一次函数调用，在追求极致性能的场景下，能省则省。 - 上报要异步：记录到的耗时日志或上报逻辑，一定要做异步处理或者缓冲。否则，一个慢查询的同步上报操作，很可能把后续的快查询都给拖垮。
- 回调别阻塞：计时结束后的回调函数里，切忌做任何阻塞性操作，比如同步写磁盘、发起HTTP请求。这会让当前连接池里的连接被卡住，影响整个应用的数据库访问。
QueryContext 和 ExecContext 必须单独处理
这里有个大坑，尤其对于Go 1.8以上的项目。从Go 1.8开始，引入了带 context 的方法（QueryContext, ExecContext），它们和旧版的 Query、Exec 是独立的接口方法，不存在重载或继承关系。如果你只包装了旧方法，那么所有带 context 的调用都会绕过你的监控，直接跑到底层驱动去了。
所以，在具体实现时，你的包装 Conn 类型必须同时实现以下几组接口：
driver.Conn（包含基础的Query、Exec方法）driver.ConnPrepareContext（以支持PrepareContext）driver.QueryerContext和driver.ExecerContext（专门覆盖QueryContext和ExecContext）
漏掉其中任何一个，对应的调用路径就会失去监控。一个常见的错误就是只实现了 Query，结果上线后发现用了 db.QueryRowContext 的查询全都没有日志。
记录内容至少包含 SQL 摘要、参数占位符、耗时和错误状态
记录什么内容也很有讲究。把完整的SQL语句（尤其是那些带着长字符串或二进制参数的）一股脑全记下来，既浪费存储空间，又可能泄露敏感数据。正确的做法是提取“摘要”：
- 用正则表达式把SQL里的字面量替换成占位符
?。例如，SELECT * FROM users WHERE id = 123应该被记录为SELECT * FROM users WHERE id = ?。 - 参数部分，可以记录参数切片
[]interface{}的长度，以及每个值的reflect.TypeOf类型，具体值就不要记了。 - 耗时建议用纳秒级的整数（
duration.Nanoseconds()），这样后续做聚合分析会更方便。 - 错误状态必须判断
err != nil，并且最好能区分错误来源：是数据库返回的SQL错误（比如pq.Error），还是网络超时、连接中断这类底层错误。
一个简单的记录片段看起来是这样的：
log.Printf("sql: %s, args: %v, duration: %dns, error: %v",
sqlSummary, argTypes, dur.Nanoseconds(), err)
注意连接池复用对计时精度的影响
最后，还得考虑连接池带来的微妙影响。一个 *sql.DB 实例背后是一个连接池，同一个物理连接可能被多个goroutine轮流使用。计时本身不受影响，但如果你在 Conn 对象上挂了一些用于统计的变量（比如累计执行次数），就要小心并发读写的数据竞争问题了。
还有一个更隐蔽的坑：某些驱动（比如 mysql）会在连接空闲时自动发送 PING 语句来保活，这些内部调用同样会经过你的包装器。如果不加以过滤，这些探活语句的耗时就会混入你的业务监控数据，造成干扰。
- 过滤探活语句：推荐根据SQL文本前缀进行过滤，比如忽略以
"SELECT 1"、"/* ping */"开头的语句。 - 选对统计维度：做统计时，优先考虑用goroutine ID或者trace ID（如果集成了OpenTelemetry）来关联，而不是基于连接对象。
- 规避锁竞争：在高并发场景下，避免使用
sync.Mutex来保护全局计数器；改用atomic原子操作，或者采用每个goroutine局部累加、定期汇总刷新的策略。
说到底，给SQL驱动插桩计时逻辑本身并不难。真正的挑战在于，如何让监控体系本身不成为性能瓶颈、不污染业务延迟、不因驱动实现的细节而失效。举个例子，lib/pq 驱动的 Query 方法内部可能会拆分成多次网络读取，如果你只包装了最外层的方法，那么实际慢在SQL结果解析阶段的时间就监控不到了——这种情况下，就需要结合 pprof 或数据库端的 pg_stat_statements 这类工具进行交叉验证，才能找到真正的瓶颈。
