应使用 atomic.addint64 而非普通 int 实现高频并发计数，因其通过 cpu 原子指令保证线程安全、无锁、低开销；需声明为 int64 类型，配合 atomic.loadint64 读取、atomic.swapint64 快照重置，并用 gaugefunc 对接 prometheus 避免采集锁。
为什么不能直接用普通 int 做执行计数
高频写场景下，多个 goroutine 同时对一个 int 变量做 count++，结果大概率不准——这不是 Go 特有，而是所有语言共享的竞态问题。Go 的 go run -race 会立刻报出 Read at ... by goroutine N / Previous write at ... by goroutine M 这类错误。用 sync.Mutex 虽然安全，但锁开销在每秒数万次 DB 执行统计中会明显拖慢吞吐，尤其当统计逻辑本身极轻量时。
atomic.AddInt64 是最常用且安全的选择
Go 的 sync/atomic 提供无锁原子操作，atomic.AddInt64 对 *int64 执行加法并返回新值，底层依赖 CPU 的 CAS 或 XADD 指令，单条指令完成，无上下文切换开销。注意：必须是 int64（不是 int），因为 32 位系统上 int 可能是 32 位，而 atomic 要求内存对齐和宽度一致。
- 声明必须用
var dbExecCount int64，不能用:=推导为int - 递增统一用
atomic.AddInt64(&dbExecCount, 1)，别写dbExecCount++ - 读取用
atomic.LoadInt64(&dbExecCount)，避免非原子读导致看到“撕裂值”（比如高位刚更新、低位还没更新） - 如果需要重置计数，用
atomic.StoreInt64(&dbExecCount, 0)，别直接赋值dbExecCount = 0
如何配合 Prometheus 实现低开销暴露指标
直接把 atomic.LoadInt64(&dbExecCount) 丢给 Prometheus 的 CounterVec 会触发锁（因为 Counter 内部要加锁更新），反而抵消了 atomic 的优势。正确做法是用 prometheus.NewGaugeFunc，它不维护内部状态，只在采集时调用你提供的函数：
var dbExecCount int64
prometheus.MustRegister(prometheus.NewGaugeFunc(
prometheus.GaugeOpts{
Name: "db_exec_total",
Help: "Total number of database executions",
},
func() float64 {
return float64(atomic.LoadInt64(&dbExecCount))
},
))
这样每次 scrape 都是纯原子读，无锁、无分配、无竞争。注意：Prometheus 默认每 15s 采集一次，远低于 DB 执行频率，完全不会成为瓶颈。
reset 和 snapshot 场景下容易漏掉的细节
如果要做“每分钟执行次数”这类差值统计，需要定时 snapshot + reset。这里有两个坑：
- 不能先
Load再Store(0)—— 中间可能有其他 goroutine 增加了值，导致计数丢失。必须用atomic.SwapInt64(&dbExecCount, 0)，它原子地返回旧值并设为 0 - 如果业务要求高精度时间窗口（比如严格按自然分钟对齐），不要依赖
time.Ticker，它有调度延迟；改用time.Until(nextMinute())精确等待到下一个整点秒再触发 snapshot -
atomic.SwapInt64返回的是int64，别忘了转成float64再传给 metrics 或日志，否则 Prometheus 会拒绝接收
高频统计真正难的不是“怎么加”，而是“怎么读得准、读得轻、读得及时”。atomic 本身很简单，但和监控、重置、类型对齐混在一起时，错一个符号或一个函数名，就可能让统计失真而不自知。
