CPU 利用率过高

原因

在 MySQL 使用过程中，出现 CPU 利用率过高甚至超过100%时，与数据库存在低效 SQL 或大量行锁冲突有非常大的关系，一般都是由于大量低效的 SQL 导致，出现行锁冲突的概率非常低。

风险

若 MySQL CPU 的利用率长时间处于100%，会严重影响数据库的整体性能，极端情况下可能会出现实例 HANG 住的情况，当 HA 探测到实例 HANG 住后，为了保证用户业务的高可用性，会触发主备切换，在主备切换的过程中，业务会出现短时间的不可用，实例不可用的时长正常情况下不超过60秒。如在业务高峰期发生了主备切换，会严重影响业务的稳定和连续性。
为避免业务因 CPU 资源不足而受影响，建议提前对 CPU 利用率过高的实例进行业务优化或者升级 CPU 资源。实例发生主备切换时会出现秒级的闪断，对于长连接需要应用具备重连的机制。

解决方案

MySQL CPU 利用率过高，大部分原因与低效 SQL 有关系，通过优化低效 SQL 基本可以解决大部分问题。
MySQL 慢查询时间（long_query_time）的默认值是10s，在遇到性能问题时，若发现没有慢查询，建议将其参数调成1s ，再观察业务周期内的慢查询，进而对其慢查询进行优化。若参数调整后，在其业务周期内依然未发现慢查询，而 CPU 利用率依然偏高，建议升级 CPU 的配置，进而提高数据库的整体性能。

内存利用率过高

原因

云数据库 MySQL 的内存是重要的性能参数，常出现由于低效 SQL 请求以及待优化的数据库导致内存利用率过高甚至超过100%的情况。

风险

由于低效 SQL 请求以及待优化的数据库导致内存利用率升高的问题时，若您使用的是 MySQL 高可用版数据库，严重时还会触发内存 OOM 进而发生主备切换，主备切换过程中会导致业务短时间不可用，实例不可用的时长正常情况下不超过60秒。如在业务高峰期发生了主备切换，会严重影响业务的稳定和连续性。
为避免业务因内存利用率过高而受影响，建议您提前对内存利用率过高的实例进行业务优化或者升级内存空间。实例发生主备切换时会出现秒级的闪断，对于长连接需要应用具备重连的机制。

解决方案

MySQL 的内存大体可以分为 global 级的共享内存和 session 级的私有内存两部分：

• 共享内存是实例创建时即分配的内存空间，并且是所有连接共享的。
• 私有内存用于每个连接到 MySQL 服务器时才分配各自的缓存。
  一些特殊的 SQL 或字段类型会导致单个线程可能分配多次缓存，因此当出现 OOM 异常，都是由各个连接的私有内存造成的，通过限制数据库的连接数和优化低效 SQL，可降低内存利用率过高的风险，若 MySQL 的内存利用率依然过高，可通过升级内存配置来提升数据库的整体并发量和稳定性。详细的内存参数介绍，请参见 内存分配问题。

说明：

• 升级过程中不影响业务的正常使用，升级完成后会进行切换，仅有秒级别的闪断，请确保业务具备重连机制。
• 目前 MySQL 控制台暂不支持内存参数的修改，若将 innodb_buffer_pool_size 设置过小，可能会导致磁盘写负载过高，进而影响数据库的整体性能。
• 避免因 MySQL 内存或 CPU 资源不足而影响业务的正常运行，请为现网实例配置资源的合理告警策略，可提前发现资源不足的隐患，详情请参见 告警服务。