mysql数据库部分性能问题分析及优化

好久没更新东西，都更新在自己的本地word中了，比较忙碌，最近在python+selenium搞自动化方面的东西，后续有开发个自己的监控系统的想法（python搞比较好，虽然python掌握得很low，这个可以学，对！），python搞起来，有多余的精力再去搞鼓那些，先记录下公司刚做的一个项目的部分性能问题一些分析思路：

目前在做公司一个项目性能测试xxxxx，后端主要涉及的接口有N多个，在性能压测中出现很多性能问题，比如JDBC连接池问题、数据库瘫痪、配置问题，接口调用问题，sql问题，数据库索引问题，服务器cpu问题等，其他一些应用还需要涉及到JVM方面等。

部分性能问题已做优化：

1.目前出现的问题jdbc连接池和数据库配置问题已做相应的调整。

2.其中一个表中已添加合适的索引，从新压测后，这些问题都得到改善。

调整优化后重新压测稳定性和速度都得到很大提高，其中监测到两个sql存在性能问题，还在进一步确认中。

现在主要问题集中在：10并发压测中，整个app端界面的所有操作响应大于10s，且长时间白屏，无法正常响应。

分析：压测采用jmeter压测后端所有调用的接口，10并发混合综合压测接口，jmeter所有接口平均响应时间大于10s，tps、吞吐量较低，手动访问APP端界面的所有操作响应大于10s，且长时间白屏，无法正常响应。

后端所有服务器单独分开隔离分析，经过监控分析得出：排除应用服务器和其他一些服务器的问题（不同应用可能会涉及到连接redis，mongodb，调用其他服务器的服务等），问题集中在mysql服务器和mysql数据本身性能上。数据库服务器最直接的反应是内存方面没问题，user态的cpu利用率直接大于95%，10并发量，并不算高，cpu利用却如此高，这cpu并不算垃圾，就算垃圾也算是垃圾中的战斗机。部分人说更换更好的服务器cpu不就好了，哎，当时就想，没解决本质问题，在牛x的cpu也一样受不了，又不是很大并发下导致cpu利用率高。于是把所有接口业务拆分开，对不同接口调用进行监控分析，以及在不同数据库数据量都记录下来服务器端性能，定位到最终导致cpu瓶颈的本质问才能解决问题，确定这思路，最后范围缩小到其中一个接口业务问题，这个接口每次操作都会去写入更新两个表的数据，就经验分析，这个接口对两个表同时做数据处理，在这样的数据量下数据库方面也不会有问题，此时两张表的数据量分别为60万和200万左右，又不大。

目前定位到10并发下app端所有操作都大于10s的源头，先记录下来这些，下一步需要开发配合拉出这块业务逻辑代码、分析这代码块处理的逻辑，并且针对这块代码的执行去监控数据库的执行情况，最终定能解决问题。下周一具体分析更新。

原因及优化：

①、导致cpu利用率高的原因是每次绑定邮箱的时候程序会去判断user_info表中是否存在已绑定的邮箱号，而此时user_info表中存在60万数据，邮箱列未加索引，全表遍历数据，判断完满足条件后往user_info中插入邮箱信息（此时user_task表200万数据），并向user_task表更新三条记录。需要在user_info表的email检索列上面添加索引

②、show full processlist查看到大量sql解析所有列的语句，查看代码，程序中使用select * from user_info where email = {email}，该语句把所有列解析出来，需要耗费大量IO，该业务只判断user_info里面是否存在该邮箱就可以，所以只需要select email from user_info where email = {email}，避免过多解析增加磁盘IO开销。

优化前后数据库cpu利用率监控对比如图：

优化前：

优化后：

经过优化后，10并发下压测“绑定邮箱接口”数据库cpu使用率由之前的99%下降到5%左右。