记一次优化mysql（700w）数据的经历
1：情况
当时线上环境出现调用接口，接口无法响应问题，网站登录不上，机柜充电无法下单的情况，排查原因，发现sql堵塞着，综合分析日志数据太大，导致的。此时hold_log日志信息如下
当时通过show processlist查看mysql情况发现
执行的时间已经上千秒了，并且查看sql，通过exlpain发现sql已经走了索引，也已经最优了。因为笔者也是后来接手的，系统大概的结构已经定型，只能起一个临时方法。
临时解决方案
一、先将这种上千秒的sql查询kill id；杀掉 ，然后接口此时就已经稍微缓过来了，只要没有人查看这个日志还是可以接受的。继续优化。
二、统计一下表数量，发现已经700w的数据，只能进行按照时间进行归档，因为日志只是公司内部人查看，先将日志分批导出，如果想要查看可以申请，我在进行单独恢复到其他环境进行查看，下面进行归档删除日志过程（目的减少数据量）
工具：Navicat
- 导出的时候，先将表结构导出，以防回退的时候表结构不能对应上
- 导出数据，按照时间切割小分段导出（因为太大，一次导出会影响线上性能）这个很关键，大量的操作搞不好mysql还会瘫掉，所以只能一点一点的导出。
Ctrl+s保存，因为如果不保存导出的结果没有表名，这点要注意一下
进行导出步骤
导出到选择一个文件目录（注意：如果上面的sql没有保存，那么导出的时候源就是下面的情况，如果保存了查询，在导出，源就是保存的名字也是你的表名）
在进行导出格式设置
等待导出成功
成功之后查看数量是否一致
mysql查询的数量
打开导出的sql文件查看多少行
一致则证明导出成功
然后开始进行小部分清除（一定注意别删错了，否则你就跑路吧）
如此以往，重复操作到你指定的日期。这样最终这个日志就消减下来了，从700w消减到了90w查询果然快了，3秒内可以响应。
笔者知道这是临时方案，最终方案还得优化设计结构。先度过一劫，在开始优化。
导入注意事项
导入部分。先导入表结构，然后导入对应的sql文件
等待成功即可