可以先使用 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 出现了何种问题
有了猜测的方向之后 你就可以进一步深入去排查了
MySQL CPU占用过高原因主要有以下几种
CPU过时（比较旧的CPU）
RAM资源不足（RAM记忆体）
解决办法如下：
①临时解决方案
首先是ctrl+alt+delete快捷键打开工作管理员
然后找到下方图一中的mysqld.exe
右击移至详细资料
再来右击设定优先顺序
按照下方图二的步骤
根据占用情况调整成低于标准或者低
这个方法只能临时解决
②实际解决方法是更换CPU
总结：根据正常的mysql使用，即使大量数据往来也不会造成CPU占用过高，目前推论应该是CPU比较过时的原因，治标不治本的临时解决方案。
备注：如采取方案②你需要备份你的资料，因为更换CPU会有很大的机会需要重新安装你的作业系统。
mysql中cpu负载很高，是什么原因
1、确定高负载的类型
htop，dstat命令看负载高是CPU还是IO
看具体是哪个用户哪个进程占用了相关系统资源，当前CPU、内存谁在使用
2、监控具体的sql语句，是insert
update
还是
delete导致高负载
抓取mysql包分析，一般抓3306端口的数据
看出最繁忙的sql语句了
3、检查mysql日志
分析mysql慢日志，查看哪些sql语句最耗时
检查mysql配置参数是否有问题，引起大量的IO或者高CPU操作
innodb_flush_log_at_trx_commit
、innodb_buffer_pool_size
、key_buffer_size
等重要参数
4、检查硬件问题
CPU占用过高诊断思路
mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上
perf top，cpu主要消耗在_spin_lock
生成perf report查看详细情况
CPU主要消耗在mutex争用上，说明有锁热点。
采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。
Pstack提供更详细的API调用栈
Innodb在读取数据记录时的API路径为
row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》 _L_unlock_10151 --》__lll_unlock_wait_private
row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。
而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。
Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。
当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。
解决方案
将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。
修改my.cnf，添加如下参数并重启
[mysqld_safe]malloc-lib=tcmalloc
上周五早上7点执行的操作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。
以下是修改前后cpu使用率对比
mysql负责高可用，可以参考如下几种方案：
1.基于共享存储的方案SAN
方
案介绍：SAN(Storage Area
Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统
并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。共享存储的架构如下:
优点:
1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应用透明。
3.保证主备数据的强一致。
限制或缺点:
1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格比价昂贵。
2.基于磁盘复制的方案 DRBD
方
案介绍：DRBD(Distributed Replicated Block
Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务
器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相
同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：
优点：
1.切换对应用透明
2.保证主备数据的强一致。
限制或缺点：
1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2.一般配置两节点同步，可扩展性比较差
3.备库不能提供读服务，资源浪费
3.基于主从复制(单点写)方案
前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决MYSQL服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖
MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方
案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。
