查不到慢查询日志是因为开关在 MySQL 而非 Go 应用；需确认 slow_query_log=ON、long_query_time 设置合理，并持久化至 my.cnf；QueryRow 与 Query 性能差异可忽略，关键在正确使用防连接泄漏；慢查询常因 Go 层未下推过滤逻辑导致；连接池配置不当比 SQL 慢更致命，应合理设置 MaxOpenConns 等参数。
查不到慢查询日志？先确认 log_slow_queries 和 long_query_time 是否生效
Go 应用本身不生成慢查询日志，真正打日志的是 MySQL（或 PostgreSQL 等后端数据库）。很多同学在 Go 里翻 sql.DB 日志、加 sql.Open 的 debug flag，结果一无所获——因为慢日志开关根本不在 Go 这边。
实操建议：
- 登录 MySQL 执行
SHOW VARIABLES LIKE 'slow_query_log';，确认值为ON - 检查
long_query_time（默认 10 秒），开发环境建议设成0.1：SET GLOBAL long_query_time = 0.1; - 日志路径由
slow_query_log_file控制，常见位置是/var/lib/mysql/xxx-slow.log，不是 Go 项目目录下 - 注意：MySQL 8.0+ 默认关闭慢日志，且
SET GLOBAL在重启后失效，需写入my.cnf持久化
database/sql 的 QueryRow 和 Query 性能差异在哪
不是“用了 QueryRow 就更快”，而是用错场景会拖慢整体响应。核心区别在于连接复用和结果集处理方式。
常见错误现象：用 Query 取单行数据但没调 rows.Close()，导致连接泄漏，后续查询排队等待。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 明确只取一行 → 用
QueryRow，它自动 close，语义清晰，也省一次rows.Next()判断 - 需要遍历多行 → 必须用
Query+defer rows.Close()，否则连接池耗尽后整个 DB 操作卡住 -
QueryRow内部仍是走Query流程，性能差异可忽略，但错误使用带来的间接开销（如连接堆积）远大于函数调用本身 - 别在循环里反复调
QueryRow查同个表的多个 ID——考虑改用IN或批量 join，减少 round-trip
加 EXPLAIN 分析前，先看 Go 层有没有隐式全表扫描
很多“慢查询”根本不是 SQL 写得差，而是 Go 代码把本该下推到数据库的过滤逻辑搬到了内存里。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型场景：从 DB 拿出 10 万条记录，再用 for range + if 筛出 5 条——这时 EXPLAIN 显示 type: ALL 是对的，但问题不在 SQL，而在 Go 没让数据库干活。
实操建议：
- 所有 WHERE 条件，优先写进 SQL，而不是
rows.Scan()后用 Go 判断 - 警惕 ORM 的懒加载（如 GORM 的
Preload不加条件时默认拉全量关联数据） - 用
sql.Named参数化时，注意空字符串、零值是否意外变成WHERE status = ''导致索引失效 - 对时间范围查询，确保字段类型和参数类型一致（
time.Timevsstring），否则 MySQL 可能放弃索引
连接池设置不当比 SQL 慢更致命
db.SetMaxOpenConns 和 db.SetMaxIdleConns 配得太小，会让并发请求排队等连接；配太大又可能压垮数据库。这不是“优化 SQL”，而是守住吞吐底线。
常见错误现象：QPS 上不去，SHOW PROCESSLIST 里一堆 Sleep 状态，但 CPU 和慢日志都正常——其实是连接不够用了。
实操建议：
- 默认
MaxOpenConns=0（无限制），线上必须显式设值，推荐初值10–20 × 并发请求数 -
MaxIdleConns建议设为MaxOpenConns的 1/2～2/3，避免频繁建连/断连开销 - 配合
SetConnMaxLifetime（如 1h）防止长连接僵死，尤其在数据库重启或网络抖动后 - 用
db.Stats()定期打印OpenConnections和InUse，比任何 APM 工具都直接
慢查询日志只是线索，真正的瓶颈常藏在 Go 和数据库之间的那层连接管理里——那里没有 SQL，但决定你能不能把 SQL 跑起来。
