分类： Linux

原文链接：https://www.cnblogs.com/wyy123/p/9258513.html

用户在使用 MySQL 实例时，会遇到 CPU 使用率过高甚至达到 100% 的情况。本文将介绍造成该状况的常见原因以及解决方法，并通过 CPU 使用率为 100% 的典型场景，来分析引起该状况的原因及其相应的解决方案。

常见原因

系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读（逻辑 IO，执行查询所需访问的表的数据行数），所以系统需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。

说明：大量行锁冲突、行锁等待或后台任务也有可能会导致实例的 CPU 使用率过高，但这些情况出现的概率非常低，本文不做讨论。

本文通过一个简化的模型来说明系统资源、语句执行成本以及 QPS（Query Per Second 每秒执行的查询数）之间的关系：

• 条件：应用模型恒定（应用没有修改）。
• avg_lgc_io：执行每条查询需要的平均逻辑 IO。
• total_lgc_io：实例的 CPU 资源在单位时间内能够处理的逻辑 IO 总量。
• 关系公式：total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量

解决方法

数据管理（DMS）工具提供了几种辅助排查并解决实例性能问题的功能，主要有：

• 实例诊断报告
• SQL 窗口提供的查询优化建议和查看执行计划
• 实例会话

其中，实例诊断报告是排查和解决 MySQL 实例性能问题的最佳工具。无论何种原因导致的性能问题，建议您首先参考下实例诊断报告，尤其是诊断报告中的 SQL 优化、会话列表和慢 SQL 汇总分。

另外，如果您需要阿里云的技术支持来解决 CPU 使用率高的状况，请参见 https://market.aliyun.com/store/1682301.html。

避免出现 CPU 使用率达到 100% 的一般原则

• 设置 CPU 使用率告警，实例 CPU 使用率保证一定的冗余度。
• 应用设计和开发过程中，要考虑查询的优化，遵守 MySQL 优化的一般优化原则，降低查询的逻辑 IO，提高应用可扩展性。
• 新功能、新模块上线前，要使用生产环境数据进行压力测试（可以考虑使用阿里云 PTS 压力测试工具）。
• 新功能、新模块上线前，建议使用生产环境数据进行回归测试。
• 建议经常关注和使用 DMS 中的诊断报告。
  

  注意：关于如何访问 DMS 中的诊断报告，请参见 RDS 如何访问诊断报告。

典型示例

以 CPU 使用率为 100% 的典型场景为例，本文介绍了两个引起该状况的原因及其解决方案，即应用负载（QPS）高和查询执行成本（查询访问表数据行数 avg_lgc_io）高。其中，由于查询执行成本高（查询访问表数据行数多）而导致实例 CPU 使用率高是 MySQL 非常常见的问题。

应用负载（QPS）高

现象描述

• 特征：实例的 QPS（每秒执行的查询次数）高，查询比较简单、执行效率高、优化余地小。
• 表现：没有出现慢查询（或者慢查询不是主要原因），且 QPS 和 CPU 使用率曲线变化吻合。
• 常见场景：该状况常见于应用优化过的在线事务交易系统（例如订单系统）、高读取率的热门 Web 网站应用、第三方压力工具测试（例如 Sysbench）等。

解决方案

对于由应用负载高导致的 CPU 使用率高的状况，使用 SQL 查询进行优化的余地不大，建议您从应用架构、实例规格等方面来解决，例如：

• 升级实例规格，增加 CPU 资源。
• 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。
• 使用阿里云 DRDS 产品，自动进行分库分表，将查询压力分担到多个 RDS 实例上。
• 使用阿里云 Memcache 或者云 Redis 产品，尽量从缓存中获取常用的查询结果，减轻 RDS 实例的压力。
• 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用，考虑开启查询缓存（Query Cache）。
  

  注意：能否从开启查询缓存（Query Cache）中获益需要经过测试，具体设置请参见 RDS for MySQL 查询缓存（Query Cache）的设置和使用。

• 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
• 尽量优化查询，减少查询的执行成本（逻辑 IO，执行需要访问的表数据行数），提高应用可扩展性。

查询执行成本（查询访问表数据行数 avg_lgc_io）高

现象描述

• 特征：实例的 QPS（每秒执行的查询次数）不高；查询执行效率低、执行时需要扫描大量表中数据、优化余地大。
• 表现：存在慢查询，QPS 和 CPU 使用率曲线变化不吻合。
• 原因分析：由于查询执行效率低，为获得预期的结果即需要访问大量的数据（平均逻辑 IO高），在 QPS 并不高的情况下（例如网站访问量不大），就会导致实例的 CPU 使用率高。

解决方案

解决该状况的原则是：定位效率低的查询、优化查询的执行效率、降低查询执行的成本。

操作步骤

1. 通过如下方式定位效率低的查询：
   • 通过 show processlist; 或 show full processlist; 命令查看当前执行的查询，如下图所示：

     对于查询时间长、运行状态（State 列）是“Sending data”、“Copying to tmp table”、“Copying to tmp table on disk”、“Sorting result”、“Using filesort”等都可能是有性能问题的查询（SQL）。

     注意：

     • 若在 QPS 高导致 CPU 使用率高的场景中，查询执行时间通常比较短，show processlist; 命令或实例会话中可能会不容易捕捉到当前执行的查询。您可以通过执行如下命令进行查询：
       1. explain select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on >= 2015-01-01 and a.detail = b.detail
     • 您可以通过执行类似 kill 101031643; 的命令来终止长时间执行的会话，终止会话请参见 RDS for MySQL 如何终止会话。关于长时间执行会话的管理，请参见 RDS for MySQL 管理长时间运行查询

   • 通过 DMS 查看当前执行的查询，查询步骤如下：
     1. 在 DMS 控制台上登录数据库。
     2. 选择性能 > 实例会话，显示结果如下图所示：

        从上图可以看出，有 10 个会话在执行下面这个查询：

        1. select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on>= '2015-01-01' and a.detail= b.detail;
     3. 单击 SQL 列中的查询文本，即可显示完整的查询和其执行计划，如下图所示：

        从上图可以看出，在该查询的执行计划中，系统对两张约为 30 万行的数据表执行了全表扫描。由于两张表是联接操作，这个查询的执行成本（逻辑 IO）约为 298267 x 298839 = 89,133,812,013（大概 900 亿），所以查询会执行相当长的时间并且多个会话会导致实例 CPU 使用率达到 100%（对于同样规格的实例，如果是优化良好的查询，QPS 可以达到 21000；而当前 QPS 仅为 5）。

2. 得到需要优化的查询后，可以通过如下任意一种方式来获取查询的优化建议：
   • 通过 DMS 的优化查询获取：
     

     注意：对于 QPS 高和查询效率低的混合模式导致的 CPU 使用率高的问题，建议使用优化查询获取优化建议。

     1. 在 DMS 控制台上登录数据库。
     2. 选择 SQL 操作 > SQL 窗口。
     3. 单击优化，即可得到优化建议，如下图所示：
   • 通过 DMS 控制台上的诊断报告获取：
     

     说明：诊断报告同样适用于排查历史实例 CPU 使用率高的问题。

     1. 在 DMS 控制台上登录数据库。
     2. 选择性能 > 诊断报告。
     3. 单击发起诊断，即可创建一个针对当前实例运行情况的报告，如下图所示：
     4. 单击查看报告，查看优化建议。
        

        注意：对于 CPU 使用率高的问题，建议关注诊断报告的 SQL 优化、会话列表和慢 SQL 汇总部分。

3. 根据优化建议，添加索引，查询执行成本就会大幅减少（如下图所示，从 900 亿行减小到 30 万行，查询成本降低 30 万倍），实例 CPU 使用率 100% 的问题解决。

参考文章：https://blog.csdn.net/qq_32448349/article/details/82965878

处理MySQL的ibdata1文件过大问题

本人在对数据库进行大量的数据插入和删除的时候，发现ibdata1的占了将近一个T

ibdata1文件是什么？

ibdata1是一个用来构建innodb系统表空间的文件，这个文件包含了innodb表的元数据、撤销记录、修改buffer和双写buffer。如果file-per-table选项打开的话，该文件则不一定包含所有表的数据。当innodb_file_per_table选项打开的话，新创建表的数据和索引则不会存在系统表空间中，而是存放在各自表的.ibd文件中.

显然这个文件会越来越大，innodb_autoextend_increment选项则指定了该文件每次自动增长的步进，默认是8M.

是什么原因导致ibdata1文件会越来越大？

ibdata1存放数据，索引和缓存等，是MYSQL的最主要的数据。所以随着数据库越来越大，表也会越大，这个无法避免的。如果时间长了，越来越大，我们在处理日志和空间的时候就不是那么方便了，就不知从何入手了。接下来我们就要处理下这样的情况，分库存储数据。

该如何处理呢？

首先我们把数据库文件备份下来，然后直接删除ibdata文件（为了保险起见最好先全备一次，做到数据安全和完整），然后再重新导入数据库文件即可！

具体操作步骤如下(截图并不完整，但是首先要弄懂大概情况和原理)：

第一种方法：

1、停止业务，备份一次全库

mysqldump -uroot -ppassword –all-databases  > all_mysql.sql
2、备份完成，停止数据库

systemctl stop mariadb 或者 service mysqld stop
3、修改配置文件

在[mysqld]下增加下面配置 innodb_file_per_table=1 验证配置是否生效，可以重启mysql后,执行 #service mysqld restart
4、验证

mysql -uroot -ppassword mysql

show variables like ‘%per_table%’;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| innodb_file_per_table | ON |

+———————–+——-+

1 row in set (0.00 sec)

innodb_file_per_table的状态变为ON

5、删除ibdata1文件和日志

rm -rf ibdata1

rm -rf ib_logfile*

6、还原数据库

mysql -uuser -ppassword

source all_mysql.sql

数据文件单独存放(共享表空间改为每个表独立的表空间文件)。

第二种方法：

把数据库的表引擎为InnoDB 的数据表转为MyIsam 后，删除ibdata1，按上面方法修改成独立的表空间，在把改成MyIsam引擎的表改为InnoDB，这个就要衡量那种方法的时间耗时最短，两者取其优。数据的表和库很多的通常不建议这么做，耗时间。