Mariadb：delete造成的主从延迟

现象：mysql主从延迟上万秒

分析：

1.多次执行：show slave status\G;

发现一直卡在delete操作。

现在需要知道哪张表的delete操作这么慢。

2.从库执行：show open tables where in_use>0;

多次执行，发现这张表一直存在，随怀疑是该表的delete操作引起从库延迟。

现在需要找出这张表在做啥操作。

3.从库执行：show slave status\G;

通过执行的主库日志位置，查找当前从库在执行的sql。

4.主库执行：show binlog events in 'mysql-bin.007232' from 305625037 limit 10;

找到导致主从延迟的sql语句后，需要找开发沟通，sql是做什么的，为什么这么大的删除量。

5.和开发人员沟通结果：

A.该表是质检表，每20分钟会从其他表中导入近3天的数据进行分析，并更新该表上的时间字段为当前时间；

B.为避免数据主键冲突，导入前会把之前导入的数据全部delete；

整个过程是这样的：删除表中近3天的数据，导入近3天的数据到该表中，并更新时间字段，每20分钟重复一次；

C.每天最后一次只导入数据进行分析，不对数据进行删除，保留作为历史数据存在；

沟通完YLMB，还有这种操作，每三天的数据有几十万条，还这么任性的循环着玩。数据库压力大的时候延迟根本没法避免。丫丫的，问题总归是问题，还得想办法解决。

6.解决分析：

A.每天只会分析近3天的数据，这样可以单独建立一张表专门作为数据分析用，导入数据，分析完，删除数据，这么每20分钟循环一次。这时候的删除就不能用delete了，效率低。可以改为truncate整张表，这样速度会非常快；

B.建立另一张表存放历史数据，每天最后一次分析完后，把数据导入历史数据表；

C.完美

D.解决方案有了后，就是改程序，抽个时间窗口导数据建表了。

7.额外说明：

有些人可能会想到，使用分区表，按天做分区，每次truncate分区。这样做理论上可以，但是，我们出现过问题，在truncate分区的时候，整张表锁了很长时间没法操作。后怕，只能退而求其次。不过这方案也挺perfect的。