记一次优化mysql（700w）数据的经历

1：情况

当时线上环境出现调用接口，接口无法响应问题，网站登录不上，机柜充电无法下单的情况，排查原因，发现sql堵塞着，综合分析日志数据太大，导致的。此时hold_log日志信息如下

当时通过show processlist查看mysql情况发现

执行的时间已经上千秒了，并且查看sql，通过exlpain发现sql已经走了索引，也已经最优了。因为笔者也是后来接手的，系统大概的结构已经定型，只能起一个临时方法。

临时解决方案

一、先将这种上千秒的sql查询kill id；杀掉 ，然后接口此时就已经稍微缓过来了，只要没有人查看这个日志还是可以接受的。继续优化。

二、统计一下表数量，发现已经700w的数据，只能进行按照时间进行归档，因为日志只是公司内部人查看，先将日志分批导出，如果想要查看可以申请，我在进行单独恢复到其他环境进行查看，下面进行归档删除日志过程（目的减少数据量）

工具：Navicat

1. 导出的时候，先将表结构导出，以防回退的时候表结构不能对应上
2. 导出数据，按照时间切割小分段导出（因为太大，一次导出会影响线上性能）这个很关键，大量的操作搞不好mysql还会瘫掉，所以只能一点一点的导出。

Ctrl+s保存，因为如果不保存导出的结果没有表名，这点要注意一下

进行导出步骤

导出到选择一个文件目录（注意：如果上面的sql没有保存，那么导出的时候源就是下面的情况，如果保存了查询，在导出，源就是保存的名字也是你的表名）

在进行导出格式设置

等待导出成功

成功之后查看数量是否一致

mysql查询的数量

打开导出的sql文件查看多少行

一致则证明导出成功

然后开始进行小部分清除（一定注意别删错了，否则你就跑路吧）

如此以往，重复操作到你指定的日期。这样最终这个日志就消减下来了，从700w消减到了90w查询果然快了，3秒内可以响应。

笔者知道这是临时方案，最终方案还得优化设计结构。先度过一劫，在开始优化。

导入注意事项

导入部分。先导入表结构，然后导入对应的sql文件

等待成功即可