Go语言框架不生成SQL执行计划，仅能捕获SQL、触发EXPLAIN并解析结果；需绕过命名参数、避免事务中执行、异步分析或安全插值，并注意不同数据库和库的格式差异。
Go语言框架本身不生成或解释SQL执行计划，执行计划完全由底层数据库（如MySQL、PostgreSQL）生成和控制；框架能做的，是帮你捕获SQL、触发EXPLAIN、解析返回结果，并在关键路径上介入干预——前提是选对工具链、配对钩子时机、避开参数绑定陷阱。
sqlx + EXPLAIN：最轻量的执行计划观测方式
sqlx不内置执行计划支持，但你可以用它安全地拼接EXPLAIN语句并获取原始结果。关键点在于：必须绕过命名参数重写逻辑，否则EXPLAIN SELECT * FROM users WHERE id = :id会被sqlx转成占位符形式，而多数数据库不接受带命名参数的EXPLAIN。
- 直接使用
db.QueryRow("EXPLAIN " + yourSQL, args...)，其中yourSQL是已手动构建的、不含命名参数的SQL字符串 - MySQL返回6–12列（如
type、key、rows），PostgreSQL返回单列QUERY PLAN文本，需用strings.Contains或正则粗筛扫描类型 - 避免在事务中执行
EXPLAIN——某些数据库（如TiDB）会报EXPLAIN in transaction not allowed
GoFrame钩子中嵌入EXPLAIN分析的实操边界
GoFrame的HookFuncSelect确实能在SQL发出前拿到in.Sql和in.Args，但这里有个硬限制：你不能在钩子里同步执行另一条EXPLAIN查询，因为当前连接可能正被事务占用，且钩子上下文ctx未必携带可用的*gdb.DB实例。
- 可行做法是记录
in.Sql和采样in.Args，异步发往日志系统或监控管道，再由外部服务调用EXPLAIN并存档 - 若坚持在钩子内分析，必须提前用
gdb.New另建一个只读连接，且显式关闭，否则会泄漏连接 -
in.Sql已含问号占位符，不可直接拼进EXPLAIN——需用fmt.Sprintf或gdb.FormatSql做一次安全插值（仅限调试，禁止上线）
goqu与go-mysql-server的执行计划适配差异
goqu生成的SQL默认不带EXPLAIN前缀，而go-mysql-server作为嵌入式引擎，其EXPLAIN输出格式与MySQL Server不完全兼容——比如不支持FORMAT=JSON，且rows字段含义偏统计估算而非实际扫描行数。
立即学习“go语言免费学习笔记（深入）”；
- 用goqu时，先调
ds.ToSQL()拿到原始SQL，再手动加EXPLAIN前缀；注意goqu.From("t").Where(...).Limit(10)生成的SQL末尾有LIMIT，而MySQL 5.7+要求EXPLAIN SELECT ... LIMIT语法合法 - 在go-mysql-server中，
EXPLAIN SELECT * FROM t WHERE x > 10返回的是结构化plan.Node树，需调用node.String()转文本，而非查Rows - 两者都不支持运行时动态切换
optimizer_switch，如想测试索引合并效果，得改配置重启服务，不能靠框架API临时覆盖
真正卡住性能的往往不是“怎么拿到执行计划”，而是“拿到后没人看”或“看到type: ALL却不敢删WHERE条件”——框架能降低观测门槛，但解读和决策仍得靠人盯住key_len、filtered、Extra这些字段的实际数值，而不是只扫一眼possible_keys有没有空。
