每日一博 | 一次较波折的 MySQL 调优
春节长假某日,阳光明媚,春暖花开,恰逢冬奥会开幕,想着一定是一个黄道吉日,必能顺风顺水。没想到却遇到一个有点小波折的客户报障。 01 故障起因 故障起因是客户前一天从自建MySQL迁移到云上RDS,在执行某个并发较高的业务时出现了大量锁等待,客户当时升级了实例到最高规格,但故障依旧。客户反馈升级后的实例规格比自建实例高了一倍,自建实例上从未发生过类似情况。后客户根据当时的业务故障模拟了现场,主要是并发执行如下存储过程的时候性能很差: 02 初步诊断 从存储过程的逻辑看,比较简单,主要涉及两个SQL,一个从表t(隐藏了真实表名)中meeting_id根据传入参数值查询,具体的入参由字符型变量p_meeting_id带入;另外一个根据meeting_id和刚查出的phone_id去更新t中的phone_id为phone_id+3。表t数据量约40w左右。 第一感觉这是个简单问题,估计两个SQL的meeting_id索引没有生效,查询表上索引后果然发现meeting_id和phone_id上没有索引,建议客户在两个字段上分别创建了索引,且meeting_id为主键。此时用户执行模拟的并发脚...