show_profile在mysql 5.7中已完全移除，须改用performance schema分析存储过程性能，但需手动启用相关仪器和消费者，并注意事件覆盖、嵌套调用及非sql瓶颈。
SHOW_PROFILE 在 MySQL 5.7 中已废弃，不能用
SHOW PROFILE 从 MySQL 5.6.7 开始被标记为 deprecated，到 5.7.26 完全移除（执行会报错 ERROR 1287 (HY000): 'SHOW PROFILE' is deprecated and will be removed in a future release. Please use Performance Schema instead.）。如果你在 5.7 环境下还依赖它查存储过程耗时，第一步就得停——它根本不会返回有效数据，甚至可能掩盖真实瓶颈。
替代方案只有 performance_schema，但要注意：默认是关闭的，且开销比 SHOW PROFILE 高；必须手动启用相关消费者和仪器：
- 确认已开启：
SELECT VARIABLE_VALUE FROM performance_schema.setup_instruments WHERE NAME = 'statement/sql/call_procedure';返回YES才生效 - 必须同时启用对应 consumer：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_statements_current'); - 过程调用后，查
performance_schema.events_statements_history_long，过滤SQL_TEXT LIKE 'CALL %'，再按TIMER_WAIT排序看最慢的几条
为什么直接 EXPLAIN CALL 不行，得拆开查内部 SQL
MySQL 的 EXPLAIN 不支持 CALL 语句本身——你对 CALL my_proc() 执行 EXPLAIN，只会得到 ERROR 1064 (42000)。真正要分析的是过程体里每一条可执行 SQL，尤其是带 WHERE、JOIN、子查询或 ORDER BY 的语句。
实操建议：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 把过程体中关键 SQL 单独拎出来，用实际参数值替换变量，再套一层
EXPLAIN FORMAT=TRADITIONAL - 重点盯
type字段：出现ALL或index说明没走有效索引；key为空或不是预期索引名，大概率是参数类型不匹配导致隐式转换 - 对比
rows和实际结果集大小：如果rows=100000但只返回 3 行，说明优化器误判了选择性，可能是统计信息过期或条件写法触发了全表扫描
performance_schema 查 CALL 耗时容易漏掉的三个点
即使开了 performance_schema，也常因配置疏漏看不到过程调用链路：
-
events_statements_history_long默认只存最后 10000 条事件，高并发下很快被覆盖；需提前调大：SET GLOBAL performance_schema_events_statements_history_long_size = 100000; - 过程内嵌套调用其他过程（如
CALL inner_proc()），外层CALL记录存在，但内层不会单独成行——它被合并进外层事件的Nesting_event_id关系中，需关联events_statements_history_long自连接才能展开 -
TIMER_WAIT是纳秒单位，直接看数字不直观；建议除以 1000000000 转成秒，再用ROUND(..., 3)保留三位小数
真正卡住存储过程的，往往不是 SQL 本身
查了一圈 performance_schema 和 EXPLAIN，发现所有 SQL 的 rows 和 key 都正常，但过程整体还是慢——这时候要跳出 SQL 层，看三件事：
- 过程是否在循环里反复
SELECT ... INTO到局部变量？哪怕每次只查 1 行，1000 次就是 1000 次解析+优化+锁等待，本质是 N+1，比单条慢查询更伤 - 有没有用
SLEEP()或DO类无意义语句做“节奏控制”？这类操作不会出现在performance_schema的 SQL 事件里，但会吃掉大量TIMER_WAIT - 过程是否调用了 UDF（用户自定义函数）或触发器？它们的执行时间不会计入语句事件，得单独查
events_functions_graph（MySQL 8.0+）或改用 general log 抓原始调用流
过程慢的根因，常常藏在“非 SQL”的控制流里，而不在你盯着看的那几行 SELECT 上。
