mysql占用CPU过高解决

背景

        总结一次处理上线问题的经过。大量客户反馈说官方网站无法访问，赶紧登录数据库服务器后，居然数据库cpu飙升到1000%，业务网站无法访问。初步定位由于数据库原因，重启后，很快又飙升到1000%，没办法，只能通过监控数据库性能，定位导致数据库出现问题的语句，在找到使用该语句的接口。监控运行之后，果然发现是由于sql语句效率太低，导致数据库无法正常处理请求。

        项目上线后，会因为数据量大导致mysql cpu占用大，或业务页面卡顿，用户体验不好。需要进行对mysql数据库的监控。通过在数据库服务器运行监控mysql脚本，可以有效定位到出现问题的功能点。在针对mysql中运行的语句进行优化。这时，数据库监控脚本的重要性便体现出来。

准备

        在linux服务器中编写如下脚本文件，注意修改 IP 端口 用户 密码: 

       [[email protected] ~]# vi mysql-detail-status.sh 

mysqladmin -uroot -proot  -r -i 1 ext |\
awk -F"|" \
"BEGIN{ count=0; }"\
'{ if($2 ~ /Variable_name/ && ++count == 1){\
    print "----------|---------|--- MySQL Command Status --|----- Innodb row operation ----|-- Buffer Pool Read --";\
    print "---Time---|---QPS---|select insert update delete|  read inserted updated deleted|   logical    physical";\
}\
else if ($2 ~ /Queries/){queries=$3;}\
else if ($2 ~ /Com_select /){com_select=$3;}\
else if ($2 ~ /Com_insert /){com_insert=$3;}\
else if ($2 ~ /Com_update /){com_update=$3;}\
else if ($2 ~ /Com_delete /){com_delete=$3;}\
else if ($2 ~ /Innodb_rows_read/){innodb_rows_read=$3;}\
else if ($2 ~ /Innodb_rows_deleted/){innodb_rows_deleted=$3;}\
else if ($2 ~ /Innodb_rows_inserted/){innodb_rows_inserted=$3;}\
else if ($2 ~ /Innodb_rows_updated/){innodb_rows_updated=$3;}\
else if ($2 ~ /Innodb_buffer_pool_read_requests/){innodb_lor=$3;}\
else if ($2 ~ /Innodb_buffer_pool_reads/){innodb_phr=$3;}\
else if ($2 ~ /Uptime / && count >= 2){\
  printf(" %s |%9d",strftime("%H:%M:%S"),queries);\
  printf("|%6d %6d %6d %6d",com_select,com_insert,com_update,com_delete);\
  printf("|%6d %8d %7d %7d",innodb_rows_read,innodb_rows_inserted,innodb_rows_updated,innodb_rows_deleted);\
  printf("|%10d %11d\n",innodb_lor,innodb_phr);\
}}

         保存后，授予可执行权限： 

        [[email protected] ~]# chomd 777 mysql-detail-status.sh 

运行

        [[email protected] ~]# ./mysql-detail-status.sh 

分析

       1.分析QPS是否过大，在用户很少的情况下QPS一般不会很高，出现超高情况先排查语句问题

        2.分析 innodb row operation 是否过大。这个是扫描的物理行数，根据需要返回

        3.可以根据接口日志进行定位慢接口何时出现。在通过以上脚本的日志 判断 改接口是否由于语句原因造成。

        4.找到可以重现的业务后，mysql中运行“ show processlist;” 找到当前运行慢的语句。这样针对业务和语句在进行优化，基本cpu占用问题即可解决。