我在 MySQL 中有一个很长的例程,其中有多个SELECT
,INSERT
和UPDATE
语句,其中包含一些IF
s 和REPEAT
s。它一直运行良好,直到最近,它挂起超过 20 秒才能完成(考虑到它过去需要 1 秒左右,这是不可接受的)。
对我来说,找出瓶颈来自哪里的最快、最简单的方法是什么?基本上,例程已经停止了,并且在某些方面......我如何在不分解例程并逐个测试每个部分的情况下找出它在哪里?
我在 MySQL 中有一个很长的例程,其中有多个SELECT
,INSERT
和UPDATE
语句,其中包含一些IF
s 和REPEAT
s。它一直运行良好,直到最近,它挂起超过 20 秒才能完成(考虑到它过去需要 1 秒左右,这是不可接受的)。
对我来说,找出瓶颈来自哪里的最快、最简单的方法是什么?基本上,例程已经停止了,并且在某些方面......我如何在不分解例程并逐个测试每个部分的情况下找出它在哪里?
如果您使用Percona Server(具有许多增强功能的免费 MySQL 发行版),您可以使用log_slow_sp_statements
配置变量为单个查询创建慢查询日志记录时间。请参阅http://www.percona.com/doc/percona-server/5.5/diagnostics/slow_extended_55.html
如果您使用的是库存 MySQL,您可以在存储过程中添加语句,将一系列会话变量设置为SYSDATE()
函数返回的值。在 SP 的不同点使用不同的会话变量。然后在测试执行中运行 SP 后,您可以检查这些会话变量的值以查看 SP 的哪个部分花费的时间最长。
分析查询可以看到相同的执行计划。这并不总是一件容易的事,但稍加阅读就会找到解决方案。我留下一些有用的链接
http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html
http://dev.mysql.com/doc/refman/5.0/en/explain.html
http://dev.mysql.com/doc/refman/5.0/en/using-explain.html
http://www.lornajane.net/posts/2011/explaining-mysqls-explain