存储过程慢不能只看CALL总耗时，必须单独分析内部SQL的执行计划：MySQL用EXPLAIN手动分析具体语句，SQL Server用SET STATISTICS XML ON捕获真实计划，PostgreSQL用EXPLAIN包裹CALL或RAISE NOTICE输出计划。
存储过程慢，不能只看 CALL proc_name() 的总耗时——它不告诉你哪条 SQL 在拖后腿。必须把内部语句单独拎出来看执行计划，否则优化就是蒙眼猜。
MySQL：用 EXPLAIN 分析存储过程里的具体语句
MySQL 存储过程本身不生成可查看的“整体执行计划”，真正要分析的是它内部执行的每一条 SQL。关键不是在过程里加 EXPLAIN，而是复制那条语句出来，在相同参数和会话环境下手动执行 EXPLAIN。
- 先确认哪条语句最可疑：在过程里加
SELECT NOW(), 'before query X';打点，运行后比时间戳间隔 - 复制该语句（比如
SELECT * FROM orders WHERE user_id = p_user_id AND status = 'paid';），把参数替换成实际值（如user_id = 12345） - 确保连接 session 设置一致：
SET SQL_MODE = @@SESSION.SQL_MODE;、字符集、时区都和调用过程时一样 - 执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...，重点盯type（是否ALL）、key（是否为NULL）、rows（预估扫描行数是否远超实际）、Extra（是否有Using filesort或Using temporary）
SQL Server：用 SET STATISTICS XML ON 捕获真实执行计划
SSMS 界面上点“显示实际执行计划”经常捕不到完整路径，尤其遇到 SET NOCOUNT ON 或动态 SQL。必须在调用前显式开启统计开关。
- 在查询窗口顶部先执行
SET STATISTICS XML ON;，再运行EXEC proc_name @p1 = 'val1'; - 结果面板会多出一个“执行计划”标签页，每个
<RelOp>节点对应一条子查询，注意对比ActualRows和EstimateRows—— 偏差超 10 倍，大概率是统计信息过期或隐式转换 - 如果过程里用了
EXEC(@sql)，执行计划里只会显示“远程查询”，得把@sql的值PRINT出来，再单独对那条字符串做EXPLAIN（或在 SSMS 里粘贴执行） - 生产环境别长期开着，临时排查完立刻关掉：
SET STATISTICS XML OFF;
PostgreSQL：用 EXPLAIN 包裹 CALL 或在函数内 RAISE NOTICE
PostgreSQL 不支持直接对 CALL 语句做 EXPLAIN，但有两种可靠方式获取内部查询的计划。
- 如果存储过程返回结果集，可用子查询包装：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM (CALL my_proc()) AS t;—— 注意加ANALYZE才能看到真实执行耗时和 I/O - 更灵活的方式是在函数体内插入调试语句：
RAISE NOTICE '%', (EXPLAIN (FORMAT JSON) SELECT * FROM users WHERE id = $1);，日志里就能看到计划 JSON - 避免在循环里反复调用
EXPLAIN，它本身有开销；只在怀疑慢的分支里加一次 - 注意：
RAISE NOTICE输出进数据库日志，需检查log_destination和log_min_messages配置是否允许输出
最容易被跳过的一步，是忽略参数类型与字段类型的隐式匹配。比如 MySQL 里传 VARCHAR 参数查 BIGINT 字段，或 SQL Server 里用 @var 代替 @param 导致参数化失效——这些都不会在执行计划里明说，但会让 key 显示用了索引、key_len 却异常小，或者 EstimateRows 完全失真。动手前，先验证变量类型是否对齐。
