MySQL CPU使用率高的原因和解决方案

当用户使用MySQL实例时，他们会遇到很高的CPU使用率，甚至100％. 本文将介绍这种情况的常见原因和解决方案，并通过典型的CPU利用率为100％的情况分析这种情况的原因以及相应的解决方案.

常见原因

在执行应用程序提交查询（包括数据修改操作）时，系统需要进行大量逻辑读取（逻辑IO，要访问该表以执行查询的数据行数），因此系统需要消耗一个大量的CPU资源来维护从属存储系统读入内存的数据的一致性.

注意: 大量的行锁冲突，行锁等待或后台任务也可能导致实例的CPU使用率过高，但是出现这些情况的可能性非常低，因此本文将不对其进行讨论.

本文使用简化的模型来说明系统资源，语句执行成本和QPS（每秒查询）之间的关系:

解决方案

数据管理（DMS）工具提供了多种功能，可帮助排除故障和解决实例性能问题，主要是:

其中，实例诊断报告是解决和解决MySQL实例性能问题的最佳工具. 无论由于任何原因导致的性能问题，建议您首先参考示例诊断报告，尤其是诊断报告中的SQL优化，会话列表和缓慢的SQL摘要.

此外，如果您需要阿里云的技术支持来解决CPU使用率过高的情况，请参阅.

避免100％CPU使用率的一般规则. 典型例子

以一个典型的方案，以100％CPU使用率为例. 本文介绍了造成这种情况的两个原因和解决方案，即高应用程序负载（QPS）和查询执行成本（查询访问表avg_lgc_io中的行数）高. 其中，由于查询执行成本高（查询访问表数据中的行数很大），因此实例CPU使用率高是MySQL中非常普遍的问题.

应用程序负载（QPS）高现象描述解决方案

对于由高应用程序负载引起的高CPU使用率，使用SQL查询进行优化的空间不大. 建议您从应用程序体系结构和实例规范的方面来解决它，例如:

查询执行成本（查询访问表数据行avg_lgc_io）高现象描述解决方案

解决这种情况的原则是: 定位低效率查询，优化查询执行效率，并降低查询执行成本.

操作步骤

按以下方式查找低效率的查询:

通过DMS检查当前执行的查询，查询步骤如下:

在DMS控制台上登录.

选择性能>实例会话，显示结果如下图所示:

从上图可以看出，有10个会话执行以下查询:

从perf_test_no_idx_01 a，perf_test_no_idx_02 b中选择b. *，其中a.created_on> ='2015-01-01'和a.detail = b.detail;

单击“ SQL”列中的查询文本以显示完整的查询及其执行计划，如下图所示:

从上图可以看出，在查询的执行计划中，系统对大约300,000行的两个数据表执行全表扫描. 由于两个表是联接操作，此查询的执行成本（逻辑IO）约为298267 x 298839 = 89,133,812,013（约900亿），因此该查询将花费很长时间执行，并且多个会话将导致实例CPU使用率达到100％（对于相同规格的实例，如果它是一个优化优化的查询，则QPS可以达到21000；而当前的QPS仅为5）.

获取需要优化的查询后，可以通过以下任意一种方式获取查询的优化建议:

根据优化建议，添加索引将大大降低查询执行成本（如下图所示，从900亿行减少到300,000行，查询成本减少了300,000倍），并且实例CPU使用率的问题是100％解决.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-303983-1.html