beego orm 不提供 explain 接口，需手动在数据库侧对捕获的 sql 加 explain 分析；开启 orm.debug = true 可输出实际执行 sql，结合 slow_query_log 与 explain format=json 定位性能瓶颈，并重点关注 key、rows、extra 三列判断索引有效性。
Beego ORM 本身不提供 EXPLAIN 输出接口，所有 SQL 执行计划必须从数据库侧抓取 —— 直接在 MySQL 命令行或监控平台里对 ORM 生成的 SQL 手动加 EXPLAIN 前缀，才是唯一可靠方式。
如何捕获 Beego ORM 实际执行的 SQL
ORM 默认不打印 SQL，需主动开启日志开关，并注意避免生产环境误开：
- 初始化时调用
orm.Debug = true（仅开发/测试环境），它会将每条 SQL 和参数输出到标准日志 - 若用
mysql驱动，连接字符串中追加&parseTime=true&loc=Local，否则时间字段解析可能出错，导致 WHERE 条件失效、索引无法命中 - 不要依赖
QueryTable("user").Filter("name", "alice")这类链式调用的“直观性”——最终生成的 SQL 可能含隐式 JOIN 或子查询，必须看日志确认 - 遇到慢查询，优先在 MySQL 的
slow_query_log中捞出完整语句，再用EXPLAIN FORMAT=JSON分析，比凭空猜测准确十倍
常见索引失效场景与 Beego 写法对应关系
很多“加了索引还慢”的问题，根源是 Beego 的字段映射或查询写法触发了隐式类型转换或函数包裹：
-
Filter("created_at__gt", time.Now().AddDate(0,0,-7))→ 若数据库列是DATETIME但 Go 结构体字段是string，ORM 可能生成WHERE CAST(created_at AS CHAR) > '...'，直接废掉索引 -
Filter("status", "active").OrderBy("-id")→ 如果status列没索引，ORDER BY id就无法利用主键索引做覆盖扫描，MySQL 会回表；应建联合索引(status, id) -
Filter("name__icontains", "tom")→ 生成LIKE '%tom%'，B+Tree 索引完全无效；如需模糊查，考虑全文索引或前置分词 - 外键字段未显式加索引：比如
User模型有DepartmentId int `orm:"column(dept_id)"`，但数据库表里dept_id列没索引，RelatedSel("department")关联查就会全表扫
关联查询的索引优化关键点
Beego 的 RelatedSel 和 LoadRelated 容易掩盖底层 SQL 质量问题，必须逐层验证：
-
o.QueryTable("order").RelatedSel("user").All(&orders)→ 实际发两条 SQL：先查 order，再用IN (1,2,3,...)查 user；若 order 返回 5000 行，第二条 SQL 的IN列表就超长，甚至被截断；应改用RelatedSel("user").Limit(100)控制批量大小 - 多对多关联（如
Post↔Tag）必须确保中间表有复合索引：KEY idx_post_tag (post_id, tag_id)和KEY idx_tag_post (tag_id, post_id)，否则RelatedSel("tags")会触发 filesort -
LoadRelated(&post, "comments", 10)的第二个参数是 limit，不是深度；它不会自动合并为 JOIN，仍是 N+1 —— 真正要 JOIN，只能手写 Raw SQL 或用QueryTable("post").RelatedSel("user").All()配合预设的rel(fk)关系
Explain 结果里最该盯住的三列
拿到 EXPLAIN 输出后，别只扫一眼 type=ref 就放心，重点看：
-
key：实际用到的索引名，为空即失效；若显示PRIMARY但rows很大，说明走了主键但没过滤，可能是 WHERE 条件没走索引 -
rows：MySQL 预估扫描行数，超过单表总行数 20% 就大概率放弃索引走全表；Beego 分页用Limit(10).Offset(10000)时，rows会显示 10010，这是正常现象，但意味着深分页性能差 -
Extra：出现Using filesort或Using temporary是严重信号，通常因ORDER BY/GROUP BY字段没索引，或关联字段类型不一致（如 int vs varchar）
真正卡住性能的往往不是 ORM 功能缺失，而是开发者把 Filter 当成黑盒，忽略了它背后生成的 SQL 是否可索引。每次加新查询逻辑，都应该养成习惯：开 Debug → 复制 SQL → EXPLAIN → 看 key/rows/Extra → 补索引或改写法。这个闭环漏掉任何一环，都可能让索引形同虚设。
