关机十分钟后才能缓解的影响因素我只能想到是温度

有，但不是大佬，也不是 MyISAM 。
线上业务，单表 20 多 G ，删除 5GB 左右的数据，3 个小时，症状：
查询正常（大部分走从机）写入延迟 2~3 秒。
主机监控 CPU 狂飙，IO 使用率狂飙。
执行完后从机重复上面症状，并且主从同步延时拉扯到 13 秒。
等从机执行完后手动 alert 了一下表触发 optimize 操作。
大概 30 分钟，监控看到的是 CPU 和磁盘使用率一直升。
后来经过百度查询到由于 optimize 的时候 mysql 是创建一份新的数据，再物理删除旧的数据。

@markgor 感觉还是不太一样，我这边的情况 cpu 是正常的，并且 optimize 早就执行完了，不是 optimize 过程中出现的
比如这次出现的问题，5 月 1 号 晚上执行的 optimize ，到今天 3 号磁盘都还是写不动，optimize 肯定是早执行完了

@neutrinos 10 平米的机房 2 台空调 24 小时开着，温度应该没问题

1.不跑任何业务的情况下，磁盘的性能？

单线程连续读，单线程连读写，单线程随机读，单线程随机写，64 线程随机读，64 线程随机写？

建议测试工具：
fio

例子：

# 安装
yum install epel-release -y
yum install fio -y

mkdir -p /tmp/diskTest
cd /tmp/diskTest

# 顺序写，单进程：
fio --name=SeqWrite --ioengine=libaio --iodepth=1 --rw=write --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData

# 顺序读，单进程：
fio --name=SeqRead --ioengine=libaio --iodepth=1 --rw=read --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData

# 随机写，单进程：
fio --name=RandWrite1Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData

# 随机读，单进程：
fio --name=RandRead1Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData

# 随机写，64 进程：
fio --name=RandWrite64Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData

# 随机读，64 进程：
fio --name=RandRead64Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData

# 如果测试时间过段，请加大上面关于容量的参数 --size ，每次加两倍。

这个步骤，是让你自己，裸磁盘与分区的大致性能，看看磁盘或 raid 是否存在问题。

比如，正常情况下，普通民用 HDD ，单线程随机写，速度大概是 1.41 MB/s 。

对比，某物理服务器，对 4 个机械硬盘，做了 3 副本纠删码，单线程随机写，性能降到 0.2 MB/s ，这里就需要优化了，不然客户会骂街。

2.老哥你的监测指标，少了一个非常重要的参数：分区与物理硬盘的 %utill ，也就是磁盘负载，就像 CPU 负载一样，值越高说明磁盘压力越大。

命令：
iostat -x -m -d 1

说明：
物理磁盘的 %utill ，指的是每块物理磁盘的负载。

分区的 %utill ，指的是，有些分区是有多个物理磁盘组成。此时分区的 %utill 也很重要。

3.上述指标，配合 iotop 命令，基本上能定位到进程。

4.最后，用命令：
strace -f -t -e trace=file -p <PID>

来跟踪进程的 IO ，看它到底在干啥。

@AnjingJingan #3 又重新认证看了下监控图，
每次写入慢=IO 100%
我觉得排障的流程应该变为：
IO 写入慢----此刻发生了什么事？是哪个进程 IO 导致 100%?
如果日志看不出来，建议可以设定监控，IO 持续 2 分钟 90%以上告警，然后远程进入看哪进程导致的。
另外可以看看 raid 卡日志，看看那个时间有没异常。

另外如 1#提及到的，涉及关机 10 分钟后才正常的好像也只有温度问题了。
如果你是用板载 raid 那很大因素是这样。
特别是 X58 的南桥芯片组，就算不 raid 温度也感人。
所以你想早日解决，建议：

1 、增加硬件温度监控；--先确定是否硬件问题
2 、做好告警，触发时候第一时间去“现场”查看凶手

碎片整理是这样的。

另外温度的确要检测一下，各物理磁盘温度，各 CPU 温度，主板温度，等等。打上时间戳，放入运维系统。

当出现问题时，看看各设备的温度。

先看 IO 延时，高的话，看是 IOPS 高还是吞吐量高，要都不高的话可能是硬件问题，要有一项高的话就 iotop,strace 什么的寻找占用高的进程。

重启跟关机再开机有区别，重启是不断电的，会跳过不少硬件检查程序

所以等待十分钟可能是不必要的，可能只是需要关机断电再开机通电。复现问题，关机再开机，如果立即恢复了就可以排除温度过高的可能