mysql数据库服务器CPU负载超过200%，mysqld进程导致的，如何解决？

可以先使用 uptime 命令查看 CPU 平均负载

那个 2 users 表示用户连接数，指的是总连接数。

那个 load average 就是系统平均负载，1 分钟、5 分钟、15 分钟系统负载的平均值。

指的是一段时间内 CPU 正在处理以及等待 CPU 处理的进程数之和的统计信息，也就是 CPU 使用队列的长度的统计信息。这个数字越小越好。

然后再用 vmstat 命令看下 CPU 是否饱和

这里面的 r 就是等待 CPU 的进程数，可以用来判定 CPU 是否饱和，当 r 值高于 CPU 数时，就意味着饱和了。

最右边那个 us，sy，id，wa，st 表示所有 CPU 的使用百分比。它们分别是 user time，system time，idle，wait I/O 和 steal time 的缩写。将 us 和 sy 的百分比加和，可以确定 CPU 是否处于忙碌状态。

如果是多核的机器还可以使用 mpstat 命令查看是否均衡

与 CPU 相关的命令还有 pidstat

这个命令展示了 CPU 消耗在了哪些进程上面，消耗过大的进程需要格外关注下。

基本上你使用上述几个命令 就可以初步了解 CPU 出现了何种问题

有了猜测的方向之后 你就可以进一步深入去排查了

请点击输入图片描述（最多18字）

经常混迹于技术社区，频繁看到这个题目，今天干脆在自己博客重复一遍解决办法：

针对mysql，sqlserver等关系型数据库单表数据过大的处理方式

如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；然后考虑分表 ；然后考虑分库。

这个题目是我所经历过的，我做的是GPS应用，早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种：表分区。 表分区的优势是，如果表结构合理，可以不涉及到程序修改。也就是说，对程序来讲依然是单表读写的效果！

所有轨迹数据存入到一个巨大的表里。有多大呢？

最大存储量超过10亿行。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹，所以线上期间最大存储只到这个数，再后来采用云架构，上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力。   每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops，距离系统设计的压测指标3000还有一大截

这张大型单表设计要点：（一个聚集索引用于写入，一个联合索引用于查询，没有主键，使用表分区）

明确主键用途：

真的需要查询单行数据时候才需要主键！

我采用无主键设计，用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键，压测写入超过5亿行的时候，写入性能缩减一半

准确适用聚集：

写入的数据在硬盘物理顺序上是追加，而不是插入！

我把时间戳字段设置为聚集索引，用于聚集写入目的设计。保证硬盘上的物理写入顺序，不浪费性能用于插入数据

职责足够单一： 

用于精准索引！

使用时间+设备联合索引，保证这张表只有一个查询用途。保证系统只有一种查询目的：按照设备号，查询一个时间段的数据。

精确的表分区：

要求查询时候限定最大量或者最大取值范围！

按天进行表分区，实现大数据量下的高效查询。这里是本文重点，按照聚集索引进行，可以让目标数据局限在更小的范围进行，虽然单表数据上亿，但是查询基本上只在某一天的的几千万里进行索引查询

每张表会有各自的特点，不可生搬硬套，总结下我这张表的特点：

只增，不删，不改！

关于不删除中：每天使用作业删除超过30天的那个分区数据除外，因为要清空旧的表分区，腾出新的表分区！

只有一个业务查询：只按照设备编码查询某个时间段

只有一个运维删除：删除旧的分区数据

这张表，是我技术生涯中进步的一个大阶梯，让我我体会到了系统架构的意义。

虽然我的这张举行表看似只有4个关键点，但是这四个非常精准的关键点设计，耗费了我一个月之久！正是这么足够精准的表结构设计，才撑起了后来压测并发量超过3000的并发写入量！压测的指标跟数据库所在的硬盘有直接关系，当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境

关于后来为什么没有更高的实际应用数值，是因为系统后来改版为云架构，使用了阿里云，更改为写入性能更高的非关系型数

单个复制组中的允许组成员（MySQL Server）的最大数量是9个。如果有更多的Server尝试加入该组时，其连接请求将被拒绝。该限制数量是通过已有的测试案例和基准测试中得出的一个安全边界，在这个安全边界中，组能够安全、可靠、稳定地运行在一个稳定的局域网中。

组中的成员之间，通过建立点对点的TCP连接与组中的其他成员进行通讯。这些连接仅用于组成员之间的内部通信和消息传递。用于建立TCP连接的地址信息由系统变量group_replication_local_address进行配置。

指示启用该系统变量的Server在执行START GROUP_REPLICATION语句时引导创建一个组，并充当种子成员。后续的其他Server如果要加入组（加入组的Server在这里称为joiner成员），则需要向创建组的成员请求加入组（接受连接请求的组成员在这里称为donor节点），创建组的成员在接收到joiner节点请求之后，会动态更改一些配置，以便将其添加到组中

有如下两种场景需要使用该系统变量来引导创建一个组：

如果组使用多主模式，则可以将无冲突的事务分散到不同的主要节点中，这样就能够一定程度上扩展写负载能力（通过多节点写来扩展一小部分IO *** 作，能够间接扩展一小部分写负载）。

由于组成员之间需要不断地相互交互消息以实现同步数据和相互告知组成员状态的目的。因此，相对于主从复制来说，预计会产生一些额外的负载，但具体多多少负载很难量化，因为它还取决于组的大小（即，组成员数量。例如：9个组成员对带宽需求大于3个成员，且内存和CPU消息也更大，因为成员数量越多，组中消息传递和处理工作就越复杂）。

可以，但是每个成员之间的网络连接必须可靠并具有良好的性能，低延迟、高带宽的网络连接是保证组复制高性能的必要条件，如果网络带宽存在瓶颈，可以参考"6.3 消息压缩" 中介绍的方法来降低组复制的带宽消耗。但是，如果网络连接存在丢包的问题，可能导致重新传输造成更高的端到端延迟，这个时候，吞吐量和延迟都将受到负面影响。注意：当任何组成员之间的网络往返时间(RTT)超过5秒时，可能会触发内置的故障检测机制而导致组成员被驱逐出组（实际是否被驱逐出组，需要看具体的配置）。

这取决于连接发生问题的原因。如果连接问题是暂时的，并且重新连接的速度足够快（即，发生问题的时间很短），以至于故障检测器没有发现或者未达到故障级别，那么组成员可能就不会被驱逐出组。如果发生问题的时间足够长，则故障检测器最终会发现问题并将故障成员驱逐出组。

从MySQL 8.0版本开始，可以使用两个系统变量进行调节，这就为发生问题的组成员增加了一个继续留在组中或被驱逐出组之后重新加入组的机会：

group_replication_autorejoin_tries：设置一个组成员被驱逐出组或者与组中多数成员失联达到超时时间之后，尝试自动重新加入组的次数。设置该系统变量为非0值时，成员会按照该系统变量设置的次数每隔5分钟进行一次自动重新加入组的尝试

如果一个成员被驱逐出组，并且耗尽了自动重新加入组的尝试次数都不能成功加入组，那么将会按照系统变量group_replication_exit_state_action指定的值执行退出 *** 作。之后，如果需要将其重新加入组，你需要手动执行加入组的步骤（或者使用自动化运维脚本）。

---