Beego ORM开启SQL日志需显式设置orm.Debug = true，且必须在RegisterDataBase之后、首次使用前生效；日志仅输出SQL和参数，不包含执行耗时，需手动加时间戳或用context.WithTimeout实现慢查询监控。
Beego ORM开启SQL日志打印，但没看到慢查询
默认情况下 orm.Debug 是关闭的，光靠日志开关不够。必须显式调用 orm.Debug = true，且要在 orm.RegisterDataBase 之后、首次使用 ORM 之前设置，否则不生效。
更关键的是：日志只输出 SQL 文本和参数，不带执行耗时。你需要自己加一层包装——在 orm.NewOrm() 后，用 o.Raw() 或自定义 QuerySeter 拦截器，在每次 Exec / All / One 前后打时间戳。别依赖框架自动计时，Beego ORM 没内置这个能力。
- 开发期可临时加：
log.Println("SQL:", sql, "Args:", args, "Elapsed:", time.Since(start)) - 生产环境建议用
context.WithTimeout包裹整个查询链，超时直接报错，避免慢查询拖垮整条请求 - 注意：日志量大会压垮磁盘 I/O，上线前务必关掉
orm.Debug，改用采样方式（如只记录 >500ms 的查询）
为什么EXPLAIN显示索引命中，但Beego ORM查得还是慢
Beego ORM 的慢，大概率不在数据库执行层，而在应用层组装和传输阶段。比如 QueryTable("order").All(&orders) 返回 1000 条记录，每条结构体含 20 个字段，ORM 要做 1000 次反射赋值 + 字段类型转换，这部分开销可能比 SQL 执行还高。
另外，网络往返不是瓶颈，但“单次返回太多数据”是隐形杀手。一个 2MB 的结果集，即使数据库 10ms 执行完，Go runtime 解析成结构体+GC 回收可能吃掉 150ms。
- 优先用
Values()或ValueList()只取需要的字段，例如：o.QueryTable("user").Values(&users, "id", "name", "status") - 避免在循环里反复调用
LoadRelated，它会触发新查询；改用RelatedSel("profile")配合主查询一次性 JOIN 加载 - 确认
app.conf中RunMode = prod已生效——开发模式下 Beego 会额外做字段校验、日志埋点等，性能损失可达 40%
Beego ORM里怎么快速识别N+1查询
N+1 在 Beego 里最典型的信号是：一次 HTTP 请求，日志里出现大量重复模式的 SQL，比如全是 SELECT * FROM profile WHERE user_id = ?，且参数值逐个递增或来自上一轮结果。
不要靠肉眼数——写个简单脚本解析日志：统计相同 SQL 模板出现频次，超过阈值（如 10 次）就告警。重点盯三类语句：SELECT ... WHERE foreign_key = ?、SELECT ... WHERE id IN (?)（但参数只有一个值）、SELECT * FROM xxx LIMIT 1 频繁出现。
- 检查代码中是否漏写了
RelatedSel("xxx")，Beego 不会自动加载关联字段，必须显式声明 - 警惕
All()后再对每个元素调用LoadRelated，这是 N+1 最常见写法 - 分页场景下，
Limit(20)主查后，又对这 20 条逐条查关联数据，实际发出 20×n 条 SQL，而不是 1+n 条
Beego ORM批量操作仍慢，是不是驱动问题
不是驱动问题，是调用姿势错了。Beego ORM 的 Insert() 单条插入和 InsertMulti() 批量插入底层走的是完全不同的 SQL 路径：前者拼成多个 INSERT INTO ... VALUES (...)，后者才真正用 INSERT INTO ... VALUES (...), (...), (...) 一条语句发下去。
同样，Update() 是逐条更新，UpdateMulti() 才支持 WHERE IN 批量更新。如果业务里写的是 for _, u := range users { o.Update(&u) }，哪怕只有 100 条，也会发 100 次 round-trip。
- 插入 100+ 条数据，必须用
InsertMulti(users, batchSize)，batchSize 建议设为 100–500，太大容易触发 MySQL packet size 限制 - 更新状态类字段（如 status=2），优先用
QueryTable("order").Filter("id__in", ids).Update(orm.Params{"status": 2})，不加载实体对象 - 确认 MySQL 服务端配置了
max_allowed_packet = 64M，否则InsertMulti在大数据量时静默失败
Beego ORM 的性能陷阱大多藏在“看起来没问题”的链式调用和默认行为里。比如 RelatedSel 漏写、All() 返回全字段、Insert() 循环调用——这些写法在小数据量下毫无压力，一到线上并发或数据量上升，立刻暴露。真正的优化起点不是调参数，而是先打开 SQL 日志，盯着每一条语句的来源和频次看三分钟。
