Navicat 不支持对存储过程生成图形化执行计划，仅支持独立的 SELECT/UPDATE/INSERT/DELETE 语句；需手动提取过程内SQL并代入真实参数后使用 EXPLAIN 分析，或通过命令行结合 profiling 与 SHOW PROFILE 定位性能瓶颈。
Navicat 无法直接对存储过程生成图形化执行计划
Navicat 的「执行计划」按钮（Explain）只作用于当前编辑器中**独立的 SELECT/UPDATE/INSERT/DELETE 语句**，不支持对 CALL proc_name() 或存储过程体内的 SQL 自动提取并分析。你右键存储过程 →「对象信息」或双击打开定义后点「执行计划」，按钮是灰色的，或者点了没反应——这不是权限或版本问题，而是功能根本未实现。
必须拆解存储过程，手动对内部 SQL 调用 EXPLAIN
存储过程本质是一组预编译 SQL 的封装，执行计划取决于它实际运行时的每条语句，而非过程本身。要分析性能瓶颈，得把过程体里的关键查询单独拎出来：
- 在 Navicat 中右键存储过程 →「编辑」，复制其
BEGIN ... END内部的某条核心查询（比如带WHERE和JOIN的SELECT） - 新建查询窗口，粘贴该语句，确保参数已替换为真实值（如把
WHERE id = p_id改成WHERE id = 123） - 选中该语句 → 点工具栏
Explain按钮，或按快捷键Ctrl+E（Windows）/Cmd+E（macOS） - 注意：MySQL 中若过程含动态 SQL（
PREPARE+EXECUTE），这部分无法静态分析，只能在运行时用SHOW PROFILE或开启slow_query_log捕获
MySQL 存储过程中调用 EXPLAIN 的替代命令行方式
如果 Navicat 图形界面受限，或需批量验证多个分支路径，推荐用命令行直连后执行：
- 连接 MySQL 后，先启用会话级分析：
SET profiling = 1; - 执行存储过程：
CALL my_proc(42); - 查出最耗时的查询 ID：
SHOW PROFILES; - 对具体 ID 查执行细节：
SHOW PROFILE FOR QUERY N;（N 是上一步的 Query_ID） - 更进一步可结合
EXPLAIN FORMAT=JSON对其中某条慢 SQL 单独重跑，获得可保存的 JSON 计划
这个流程绕开了 Navicat 的 UI 限制，也避开了「过程内变量不可见」「参数未绑定导致索引失效」等常见误判点。
容易忽略的关键点：参数绑定影响执行计划准确性
直接在 Navicat 查询窗口里写 EXPLAIN SELECT * FROM orders WHERE user_id = ?，Navicat 会传入 NULL 或默认值，优化器可能选错索引；而存储过程里 user_id = p_user_id 在运行时才绑定真实值。所以：
- 不要用占位符
?测试，必须代入真实值（如user_id = 1001） - 若过程逻辑依赖输入值范围（如小范围走索引、大范围走全表），需分别测试边界值
- MySQL 8.0+ 可用
EXPLAIN ANALYZE实际执行一次，但会修改数据（慎用于 UPDATE/DELETE 分支）
真正决定执行计划的是运行时的实际参数和统计信息，不是存储过程的定义文本。
