beego orm 查询不返回耗时，需手动包裹 time.now() 计时或封装 ormwrapper 结构体；推荐结合 context.withtimeout 主动中断超时查询，并启用 mysql 慢查询日志交叉分析根因。
Beego ORM 查询不暴露耗时，必须手动包裹计时逻辑
Beego 的 orm.QueryTable 或 o.Read/o.QueryTable("user").Filter("id", 1).One(&u) 等方法，底层调用的是 database/sql 的 Query 和 Exec，而这些标准接口本身不返回执行耗时——你拿到的 error 或结构体里没有 duration 字段。这意味着靠“查返回值”完全无法识别慢查询。
真正能插桩的位置只有两个：SQL 构造完成、准备执行前；以及查询结束、结果返回后。所以不能依赖 Beego 自带日志开关（如 beego.BeeLogger 的 SQL 日志），它只打语句，不带时间戳。
- 最轻量做法：对关键查询显式加
time.Now()和time.Since() - 更可持续的做法：封装一个带计时和上下文超时的
OrmWrapper结构体，嵌套原orm.Ormer，重写Read、One、All等方法 - 不要试图 patch Beego ORM 源码或修改
github.com/astaxie/beego/orm内部逻辑——升级框架即失效，且 Beego v2 已转向模块化设计，补丁维护成本极高
用 context.WithTimeout 主动中断并标记超时查询
很多慢查询卡在数据库响应上（比如锁等待、网络抖动、主从延迟），仅靠 time.Since() 只能得到总耗时，无法区分是 Go 层阻塞还是 DB 层卡死。用 context.WithTimeout 能让查询在指定时间后主动退出，并留下明确的错误信号。
Beego ORM 支持传入 context.Context（v2.0+ 版本），但默认不启用。你需要显式构造带超时的 ctx，并透传到底层 database/sql：
- 调用前：用
ctx, cancel := context.WithTimeout(context.Background(), 1500*time.Millisecond) - 调用时：将
ctx传给支持 context 的方法，例如o.QueryTable("order").Filter("user_id", uid).All(&orders, "id", "created")不支持，但o.Raw(sql, args...).Prepare().ExecuteContext(ctx)支持 - 错误判断：检查
errors.Is(err, context.DeadlineExceeded)，命中即为慢查询告警信号
注意：Beego v1.x 不原生支持 context，需升级或自行 wrap database/sql.DB 并替换 orm.RegisterDriver 注册的连接池。
MySQL 侧开启 slow_query_log + log_queries_not_using_indexes 是必要补充
Beego 层的计时只能告诉你“这条查询慢”，但无法告诉你“为什么慢”。真正要定位根因，必须打开 MySQL 的慢查询日志，并强制记录未走索引的查询——因为很多“不超阈值但正在恶化的查询”，在数据量上涨后会突然变慢，却不会被 Beego 层捕获。
- 临时开启（生产可用）：
SET GLOBAL slow_query_log = ON、SET GLOBAL long_query_time = 0.5、SET GLOBAL log_queries_not_using_indexes = ON - 永久配置（推荐）：在
/etc/my.cnf的[mysqld]下添加：slow_query_log = 1、slow_query_log_file = /var/log/mysql/slow.log、long_query_time = 0.5、log_queries_not_using_indexes = 1 - 验证是否生效：执行
SELECT SLEEP(1)后检查日志文件是否有记录，并确认SHOW GLOBAL STATUS LIKE 'Slow_queries'计数增长
Beego 应用发出去的 SQL，只要满足 MySQL 的慢条件，就会被完整记录（含执行时间、锁等待时间、扫描行数等），这才是分析执行计划（EXPLAIN）和优化索引的可靠依据。
Beego 日志与 MySQL 慢日志要交叉比对，避免误判
Beego 层记录的“慢”和 MySQL 日志里的“慢”可能不一致——前者是 Go 到 DB 返回的总耗时，后者是 MySQL 实际执行耗时。常见偏差场景包括：
- 网络延迟高：Beego 记 800ms，MySQL 日志只记 120ms → 说明瓶颈在传输层
- 连接池打满：Beego 等待获取 DB 连接就花了 600ms，实际执行才 50ms → MySQL 日志无记录，但 Beego 日志显示“慢”
- 事务未提交导致锁等待：MySQL 日志中该 SQL 耗时 2s，但 Beego 层没设超时，卡住 5s 才返回 → Beego 日志时间 > MySQL 日志时间
排查时务必同时打开 Beego 的 SQL 执行日志（beego.InsertLog 或自定义 ORM wrapper）和 MySQL 慢日志，按时间戳+SQL hash 对齐，否则容易把连接池问题当成 SQL 性能问题去优化。
