MySQL 8.0存储过程因总执行时长触发慢查询日志的问题咨询

1. MySQL 8.0是否更改了存储过程慢查询的统计方式？ #

是的，MySQL 8.0确实调整了存储过程的慢查询统计逻辑：

• 在MySQL 5.7中，慢查询日志仅会记录存储过程内部单个超过long_query_time阈值的语句，不会将整个存储过程的总执行时长作为一个独立查询统计。
• 升级到8.0后，CALL调用语句本身会被当作一个独立查询来统计总执行时长，只要总时长超过long_query_time，就会被记录到慢查询日志中，无论内部单个语句是否符合慢查询条件。

2. 有没有办法避免将存储过程的总运行时长作为单个慢查询记录？ #

可以通过以下几种方案解决：

• 启用log_slow_sp_statements变量（推荐，MySQL 8.0.16+支持）
  该变量控制是否记录存储过程内部的慢语句，开启后慢查询日志会只记录存储过程中单个超过阈值的语句，不再把整个CALL的总时长作为慢查询记录。
  临时生效命令：

  SET GLOBAL log_slow_sp_statements = ON;
  

  永久生效需在my.cnf/my.ini中添加：

  log_slow_sp_statements = ON
  

• 调整long_query_time阈值
  如果业务允许，可适当调大long_query_time的值，使存储过程总时长不超过该阈值。但此方法可能会遗漏其他真正的慢查询，属于治标不治本的方案。

• 拆分执行逻辑
  将批量归档的循环逻辑拆分，通过外部调度（如crontab）分多次调用存储过程，确保每次CALL的执行时长不超过long_query_time。

• 不推荐：调整全局慢查询记录规则
  修改log_slow_statements变量关闭CALL语句的慢查询记录，但这会影响其他正常慢查询的监控，不建议使用。

内容的提问来源于stack exchange，提问作者Billy Hsu