mysql存储过程性能监控和分析

公司当前版本的系统大量的使用了存储过程，有些复杂的过程套过程，一个主调用者可能最多调用其它几十个小的业务逻辑和判断，不要说这么做很不合理，在大陆，目前至少30%的证券交易系统代码都是用存储过程写业务逻辑的，包括sql server/oracle/mysql，三个版本都有，所以BS把业务写在存储过程的同学们不要小看，很可能你每天都在用着用存储过程开发的世界上最稳定的系统之一。

在mysql 5.6版本中，在performance_schema.events_statements_history和events_statements_history_long里面存储了所有最近执行过的存储过程以及存储过程中的SQL语句，只不过这个版本的设计并没有考虑到那些SQL是独立执行的，那些是包含在存储过程中的。所以，这个还是挺麻烦的。

在mysql 5.7中，同样是在performance_schema.events_statements_history和events_statements_history_long表中，能够看到两者的区别，如下所示：

create procedure sp_test

BEGIN
insert into t1(name) values('abafewefwefw'),('abafewefwefw11111');
delete from t1 limit 1;
END

对于嵌入在存储过程中的sql语句，object_type和object_name这一列指出了对象的名字。对于存储过程call本身，则都为空。至少在5.6以及之前的版本，还是得借用慢日志。

因为这两个表都是FIFO的性质，所以在设置setup_instruments的时候，不能把所有的statement都启用，这样会有很多元数据的语句，导致这个表增长的超级快（具体看event_name一般能够猜测出来，不过abstract的必须全部启用，否则statement相关的事件就会禁用掉，这是先决条件）。