核心手段是用 sql.Register 注册带计时的包装驱动（如 pg_timed），需完整实现 driver.Driver 及 Conn 相关接口（含 Context 版本），对 SQL 摘要化、纳秒级计时、异步上报，并过滤探活语句。
用 sql.Register 注册带计时的驱动是核心手段
go 标准库的 database/sql 本身不提供执行耗时钩子，必须在驱动层拦截。不能直接改原生驱动（如 github.com/lib/pq），而是用包装器注册新驱动名——比如注册为 pg_timed，再在应用里用这个名打开连接。
关键点在于：包装器需实现 driver.Driver 接口，且在 Open 返回的 driver.Conn 中，把所有执行方法（Exec、Query、QueryContext 等）包一层计时逻辑。
- 计时必须用
time.Now()+.Sub()，避免用time.Since()（它内部也调用Now，但多一次函数调用开销） - 日志或上报逻辑要异步或缓冲，否则慢查询会拖垮快查询
- 不要在计时回调里做阻塞操作（如同步写磁盘、HTTP 请求），否则会卡住整个连接池
QueryContext 和 ExecContext 必须单独处理
Go 1.8+ 引入了带 context 的方法，它们和旧版 Query/Exec 是独立接口方法，不重载也不继承。如果只包装旧方法，带 context 的调用会绕过监控，直接走底层驱动。
实操上，你的包装 Conn 类型必须同时实现：
-
driver.Conn（含Query、Exec） -
driver.ConnPrepareContext（支持PrepareContext） -
driver.QueryerContext和driver.ExecerContext（覆盖QueryContext、ExecContext）
漏掉任一接口，对应调用就无法被拦截。常见错误是只实现了 Query，结果发现用了 db.QueryRowContext 却没日志。
记录内容至少包含 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 上挂了 per-connection 的统计变量（比如累计执行次数），会被并发读写破坏。
更隐蔽的问题是：某些驱动（如 mysql）会在连接空闲时自动发 PING，这些内部调用也会经过你的包装器——若未过滤，会混入业务监控数据。
- 推荐按 SQL 文本前缀过滤，如忽略以
"SELECT 1"、"/* ping */"开头的语句 - 统计维度优先用 goroutine ID 或 trace ID（如有 OpenTelemetry）关联，而非连接对象
- 高并发下，避免用
sync.Mutex保护全局计数器；改用atomic或每 goroutine 局部累加后定期 flush
真正难的不是插桩，而是让监控数据不污染业务延迟、不掩盖真实瓶颈、不因驱动细节失效。比如 lib/pq 的 Query 内部可能拆成多次网络读，你只包了外层，实际慢在解析阶段——这种就得结合 pprof 或数据库端 pg_stat_statements 交叉验证。
