Mysql服务器负载很高，性能问题排查思路是怎样的

对于包括 mysql 在内的大多数数据库系统而言

性能问题的排查主要有以下方向：

1. 需求的不合理造成的性能问题

比方说，不需要实时更新的内容，被要求做成实时更新

2. 架构的不合理造成的性能问题

比方说，不适合数据库保存的数据，被存放在数据库中

或者，频繁访问但是很少变更的数据，没有做缓存

3. 查询语句的不合理造成的性能问题

比方说，重复执行相同的 SQL 会造成资源浪费

或者，大量复杂的 join 语句会导致查询效率低下

4. 数据库设计的不合理造成的性能问题

比方说，盲目追求三范式、四范式，有时候并没有必要

5. 硬件配置的不合理造成的性能问题

比方说，数据库服务器的 io 性能、CPU 、网络状况，都会影响性能

以上这些都是性能问题定位和调优的方向

宕机服务器排查故障方法

1、在运行环境的问题中，最普遍的问题时磁盘空间耗尽。

2、在性能问题中，最普通的服务器宕机原因确实是运行很糟糕的SQL，但也不一定都是这个原因，比如也有很多问题时由于服务器Bug或错误的行为导致的。

3、糟糕的Schema和索引设计是第二大影响性能的问题。

4、复制问题通常由于主备数据不一致导致。

5、数据丢失问题通常由于操作的错误操作导致，并总是便随着缺少可用备份的问题。

6.由于系统原因，导致的服务器宕机，一般重启下服务器就可以。

明白了服务器宕机的原因，我们就可以采取相应的措施来排查。宕机服务器如何排查故障

1.1 top

1.2 vmstat

r 表示可运行进程数目，数据大致相符；而b表示的是 uninterruptible 睡眠的进程数目；swpd 表示使用到的虚拟内存数量，跟 top-Swap-used 的数值是一个含义，而如手册所说，通常情况下 buffers 数目要比 cached Mem 小的多，buffers 一般20M这么个数量级；io 域的 bi、bo 表明每秒钟向磁盘接收和发送的块数目(blocks/s)；system 域的 in 表明每秒钟的系统中断数(包括时钟中断)，cs表明因为进程切换导致上下文切换的数目。

说到这里，想到以前很多人纠结编译 linux kernel 的时候 -j 参数究竟是 CPU Core 还是 CPU Core+1？通过上面修改 -j 参数值编译 boost 和 linux kernel 的同时开启 vmstat 监控，发现两种情况下 context switch 基本没有变化，且也只有显著增加 -j 值后 context switch 才会有显著的增加，看来不必过于纠结这个参数了，虽然具体编译时间长度我还没有测试。资料说如果不是在系统启动或者 benchmark 的状态，参数 context switch>100000 程序肯定有问题。

1.3 pidstat

如果想对某个进程进行全面具体的追踪，没有什么比 pidstat 更合适的了——栈空间、缺页情况、主被动切换等信息尽收眼底。这个命令最有用的参数是-t，可以将进程中各个线程的详细信息罗列出来。

-r： 显示缺页错误和内存使用状况，缺页错误是程序需要访问映射在虚拟内存空间中但是还尚未被加载到物理内存中的一个分页，缺页错误两个主要类型是

-s：栈使用状况，包括 StkSize 为线程保留的栈空间，以及 StkRef 实际使用的栈空间。使用ulimit -s发现CentOS 6.x上面默认栈空间是10240K，而 CentOS 7.x、Ubuntu系列默认栈空间大小为8196K

1.4 其他

while :do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'sleep 1done

2.1 iostat

3.1 netstat

➜ ~ netstat -antp #列出所有TCP的连接

➜ ~ netstat -nltp #列出本地所有TCP侦听套接字，不要加-a参数

3.2 sar

3.3 tcpdump

---