作者介绍
魏亚东
大型银行
软件开发中心三级经理
资深架构师，杭州研发部数据库专家团队牵头人和开发中心安全团队成员，负责技术管理、数据库、安全相关工作；
年加入大型银行软件开发中心，致力于推动管理创新、效能提升，提供全面技术管控，推动自动化实施，实现业务价值的高质量快速交付；同时作为技术专家，为生产安全提供技术支持；负责过教培、预付费等SaaS产品和数字生态基座（组装式应用程序ComposableApplications）等。
分享概要
一、系统性能问题五大特性
二、系统性能排查方略
三、MySQL开发规范和常见调优策略
四、MySQL性能管控体系
五、未来展望
一、系统性能问题五大特性
如果大家了解一些方法论的话，应该听过两个原则：一个是海恩法则，强调量变引发质变；另一个是老生常谈的墨菲定律，强调会出错的事总会出错。针对这两个原则，我总结了系统性能问题的五大特性。
1）系统响应慢
不论负载情况如何，系统应用程序一直特别慢，响应时间长。
2）时间序列日益缓慢
负载稳定，但系统随着时间推进越来越慢，到达某个阈值后，系统可能会被锁定或因大量错误出现而崩溃。
3）突发混乱
系统稳定运行，在某一时刻突然出现大量错误。
4）局部功能异常
用户访问部分页面异常，上图右下角图片是用F12对访问谷歌页面进行的截图，从中可以看出，我们访问谷歌时一直超时，无法访问。
5）随负载变化越来越慢
用户量增加时，系统明显变慢，用户离开系统后，系统恢复原状。上图左下角的图片展示了CPU的使用情况，其从%负载恢复到常态化，后续随着用户增加又逐渐涨至%负载。
二、系统性能排查方略
1、系统性能排查方略方法论
系统性能排查方略可总结为以下两点：
1）积极沟通，减小影响
利用5W1H原则了解问题现象，即什么问题、在什么时间、什么地点、如何发生、何人处理。同时还要收集现场信息，包括常见的日志信息、流量信息等，尽量做到全面排查。
安抚客户，减小客户影响。一件小事可能会由于客户恐慌性的增长酿成大事故。
基于历史经验紧急应急。
2）大胆推敲，合理论证
根据异常信息要大胆推断、合理论证，切忌“我推断就是这样，但我就不证明”；
进行全链路考量，切忌单点揣测，比如直接认定数据库有问题，但是经分析来看，数据库负载实际上没问题，而是网络问题或中间件问题；
问题解决必须包含临时方案和最终方案。用临时方案以最快的方式消除影响，然后针对问题做最终方案，避免后续类似问题带来的隐患。
为此，我通过鱼骨图进一步描述问题的排查方式：
1）消除影响
首先需要消除对客户的影响，其次要消除对系统的影响，可以通过历史经验紧急应急或其他方式帮助客户或系统避开问题。
2）收集现场
这一步强调日志的完备，同时我们需要知道发生问题时的问题数据和系统数据，才可通过数据进行重演。
3）明确问题范围
判断发生的是个别交易问题还是普遍性问题。如果是个别交易问题，我们可以很快定位交易当时做过哪些改变；如果是普遍性问题，我们要判断哪些客户、客流受到影响，以及这一问题是否会对其他方面造成影响。
4）问题分析
问题分析包括两个方面，一方面是系统级链路分析，从最早的端到端的链路进行统一排查；另一方面是交易级链路分析，从交易进来后经过中间件到数据库返回，对整个交易级链路进行分析。
5）问题解决方案
经过之前的一系列步骤，最终我们就可以制定问题的解决方案。在制定解决方案时，一般会进行数据修复和程序修复，在环境中同步验证，并将修改后的部分归并至后续版本中，避免导致类似问题重复发生。
6）问题总结
这一步主要是针对问题进行复盘，从中发现优化点，并从问题的处理方式中总结经验教训，然后进行一些横向排查，沉淀为相关经验。
下面向大家讲述性能问题排查，其中包括两大方面：系统环境和运行环境。
1）系统环境
我们原则上通过APM工具监控系统环境。业界已经有些很好的开源监控工具，比如Prometheus、Zabbix等，可以利用这些工具监测CPU负荷、lO负荷、内存负荷以及网络负荷。
2）运行环境
可以将运行环境的问题大致分为以下三类：
①数据库
日志信息
对于MySQL，首先查看其错误日志，通过mysql.err直接查看当时到底有什么问题；如果交易比较缓慢，可以从慢SQL日志（一般是slow-queries.log）中查看，原则上大于10秒的交易都会在这里体现；接下来看事务日志，通过binlog查看当时交易的情况，如果是备库重演的一些问题，可以看主备中继日志，通过relaylog查看备库重演的状态。
对于Oracle也大体相似，可以通过监听日志listener.log、lsnrctlstatus查看监听器的状态，Oracle中有一个报警日志，通过alert.log可以查看当时发生的事件。我们还可以进一步打AWR报告和ASH报告，对数据库进行监控，这一点MySQL不如Oracle。除此之外，Oracle也提供了一些历史快照信息表，比如dba_hist_sqlstat和dba_hist_snapshot，可以通过这两张快照表获取需要的任意快照时间的处理信息。最后，可以通过会话信息，查看当前会话有哪些中间件正在访问，以及整个会话的状态。
性能分析
进行性能分析时，我们可以查看执行计划。对于MySQL，我们可以通过explain语句看当时的执行计划，到底有没有走索引，索引走得好不好。对于Oracle，我们可以通过v$sql_plan和dba_hist_sql_plan查看执行计划变更的原因，针对执行计划对索引进行重建。除此之外，我们还要对死锁进行分析，并处理等待事件。
②中间件
对于中间件，例如业界使用较多的WAS、Liberty、Tomcat以及国产的东方通等，我们可以查看它的一些线程信息。这里建议大家打出3~5个javacore，一般是1分钟打一个，这样可以通过IBM的jca.jar工具对比分析问题出于哪个线程，或者线程卡在何种情况之下。
如果涉及到OOM（内存溢出），可以打出heapdump的信息，再通过IBM的ha.jar工具进行分析。
我们可以通过GC信息看是否因为服务器fullgc导致系统持续夯住，如果是，可以对vm信息进行调优。除此之外，中间件还会打一些日志信息，可以从中发现当时发生的问题。最后可以监控一些中间件的资源信息，包括数据库连接池、线程池和一些web容器。
③应用程序
若发现数据库和中间件都没有问题，我们再看应用程序。
对于前台来说，我们看是不是因为它在前台做了缓存，没有实时刷新，因此导致新请求获得老交易，最终出现问题。除此之外可以看请求连接数，浏览器的请求连接数实际上是有限的，请求连接数过大也会导致应用程序出问题。最后可以看一下是否因为资源过大导致网络传输量较大，这种问题可以通过两种方式解决，一种是资源压缩，另一种是将资源部署在CDN上。
对于逻辑层来说，我们可以看它有没有资源释放，包括数据库连接、文件读写、socket、缓存等。然后可以看事务问题，比如事务长时间没有结束，这样会卡死很多线程信息，循环处理数据库也会导致事务的持续时间较长。最后可以看多线程信息中是否包含锁等待，是否存在数据污染。
综上所述，系统性能排查有四个关键点：查看完备的日志、利用良好的工具、执行计划和