围剿慢SQL，工行MySQL研发管控和治理实践（附PPT）

生产上我们会通过监控自动查杀。但实际上，如果大家学过博弈论的话就会发现：是否查杀？到底怎么保持？这其实很难平衡，可能要通过实际场景去评估到底要不要去做。

接下来是慢SQL的治理。我们在2021年上半年大概发现了6670条慢SQL并落实版本优化，但正确率其实并不高，后续我们会考虑优化一些慢SQL的治理模型，将我们的准确率从20%再进行提升。

因为20%就意味着，我们的开发人员可能要花80%的无效时间去处理这方面的问题，显然违背了二八原则。虽然这个过程很痛苦，但我们确实收到一定的经营效果。本质上我们可以看到performance_schema可以用于监控MySQL运行过程中的资源消耗、资源等待等情况。这应该是MySQL 5.7以后会有的一个视图，这个视图中有一个表statements_summary_by_digest，它会记录每一条SQL的执行次数、时间，以及扫描的数据量等，通过对它们时间差的对比，获取真正的处理时间，从而判断语句是否存在问题。

Oracle的awr报告也是这样的道理，它是通过两个快照之间的差去进行比较。对于我们来说，比如8:00、9:00，我们的时间是一个语句。如图所示，它在8点执行了200次，执行时间是1800秒，扫描的记录数大概是1亿8000万；第二个是在9点，执行次数是300次，执行时间是2700秒。通过时间差可以判断，8:00~9:00之间只执行了100次，执行时间为900秒，那相当于一次执行花费了9秒，这其实就是一个标准的慢SQL。

虽然我不清楚在座各位所属应用对慢SQL的判定标准，默认应该是大于10秒的才算慢SQL。但对于我们金融行业来说，实际上超过一秒都属于慢SQL的处理范围。同时我们可以看到，它的扫描记录数大概是9000万，这样算来，它的扫描命中比例是900000：1，也就是说，我需要扫描90万条数据才能找到一条数据，这样的扫描比有很大的问题，显然存在效率问题，而我们的规范要求是100:1。

接下来是自动查杀。我们可以设置，当联机超过阈值时自动执行kill。但这样的做法在批量联机混合时存在风险，因为我们现在的批量联机用户实际上都是混合在一起的，而我们允许批量耗时超过10秒，这就很容易出现误杀。针对这一点，我们可以通过show processlist命令查看或者是通过 ps.threads去跟进线程的执行情况。

针对上述情况，我们做了两件事情：第一是推联机用户跟批量用户的分离，针对不同用户进行差异性处理。对于联机用户我们会进行自动查杀；而对于批量用户，因为我们判断它语句执行所花费的时间是合理的，所以就暂时先不管。

MySQL其实并不适合OLAP的应用，按照我的理解，我们可以通过大数据平台，也就是Hive、Spark，或者通过一些其他的方式去处理。这实际上就代表：MySQL仅局限于OLTP，其他像一些大数据平台等去做一些OLAP的处理，做到权责分离。

看到这里大家可能会说HTAP，我觉得这是一个老概念，属于新瓶装旧酒，以前Oracle其实就是HTAP数据库，但MySQL不行，所以需要结合实际业务场景做到功能和场景的分离。