优化Go应用数据库性能需复用连接池、避免N+1查询、精简SQL、监控定位瓶颈；关键在整体吞吐稳定、延迟可控、资源可预测。
优化 Go 应用的数据库访问性能，核心在于减少不必要的往返、控制连接开销、提升查询效率，并避免内存与 goroutine 泄漏。关键不在于单次查询多快，而在于整体吞吐稳定、延迟可控、资源可预测。
复用连接池，合理配置参数
database/sql 自带连接池，但默认配置往往不适合生产场景。过小的池子导致请求排队，过大会占用过多数据库连接和内存。
- 设置 MaxOpenConns：建议设为数据库允许的最大连接数的 70%~80%，避免打满 DB；对高并发服务，可结合压测调整，常见值在 20~100 之间
- 设置 MaxIdleConns：通常设为与 MaxOpenConns 相同或略低（如 0.8 倍），保证空闲连接可复用，减少建连开销
- 设置 ConnMaxLifetime 和 ConnMaxIdleTime：避免因连接老化（如 MySQL 的 wait_timeout）引发错误；推荐 ConnMaxLifetime ≤ 数据库 wait_timeout - 30s，ConnMaxIdleTime ≤ 5m
避免 N+1 查询，优先批量与预加载
典型陷阱是循环中逐条查关联数据，比如查 100 个用户再各自查其角色——产生 101 次查询。应改用 JOIN 或 IN 批量拉取。
- 用 IN 查询 + 预处理 一次性获取关联数据，注意 PostgreSQL/MySQL 对 IN 参数数量有限制（如 pg 默认 65535，MySQL 受 max_allowed_packet 影响），超限时需分批
- 对复杂关系，考虑 应用层 join：先查主表，提取外键 ID 切片，再用 WHERE id IN (...) 查从表，最后在 Go 中 map 关联
- 使用 sqlc、ent 或 gorm 的 Preload（谨慎开启） 自动生成高效 SQL，但需确认生成语句是否含冗余 JOIN 或 SELECT *
精简查询逻辑，减少数据搬运
数据库不是内存，网络传输、序列化、GC 都有成本。少传字段、少传行数、早过滤，就是省资源。
立即学习“go语言免费学习笔记（深入）”；
- 永远指定 SELECT 字段，避免 SELECT *；尤其表含大字段（JSON、TEXT、BLOB）时，未读字段仍会走网络和反序列化
- WHERE 条件尽量下推，不在 Go 层做 filter；例如用 WHERE status = 'active' AND created_at > $1，而非查全量再用 for 循环判断
- 用 LIMIT/OFFSET 时注意性能衰减；深分页建议改用游标分页（如 WHERE id > last_id ORDER BY id LIMIT 20）
- 聚合计算尽量交给数据库，COUNT、SUM、GROUP BY 比在 Go 中遍历 slice 统计更高效且省内存
监控与定位瓶颈，别靠猜
优化前先明确瓶颈在哪：是网络延迟？SQL 执行慢？连接等待？还是 GC 压力大？
- 用 pg_stat_statements（PostgreSQL）或 performance_schema（MySQL） 查看慢 SQL 和执行频次
- 在 Go 中用 sql.DB.Stats() 定期打印连接池状态（OpenConnections、WaitCount、MaxOpenConnections 等），观察是否频繁等待
- 给关键查询加 context.WithTimeout 并记录耗时，配合日志或 Prometheus 指标识别长尾请求
- 用 pprof 分析 CPU 和堆内存，确认是否因大量 sql.Rows.Scan 或 struct 解析导致 GC 高频或分配过多临时对象
真正的性能优化是持续过程：上线后看指标、定期 review 查询计划、随业务增长迭代配置。不复杂但容易忽略。
