Mysql删除千万级数据的方案

记录一次Mysql删除千万级数据的方案

背景：有个项目跑了一年多，没注意过，结果有一天看了下，最大的mysql表居然有四千万数据了。
震惊！自己挖下的坑还要自己坑。
因为这个表中有查询，有排序，有更新操作，如果是纯插入可能会很多，有更新和查询，四千万的表有点夸张了。所以着手进行删除。

当下最火的是chatgpt。人工智能。号称取代程序猿。于是把这个问题抛给了gpt。
gpt告诉我delete from table where id<35000000 and xxx is not null。就行了。于是，脑子一抽直接执行了。
之前我也有过类似的操作，所以就执行了。跑了十几分钟，然后就去睡觉了。

一觉醒来，同事告诉我线上很卡，我慌了，瞬间清醒。看了线上的sql 连接，
SELECT
*
FROM
information_schema.PROCESSLIST。
发现有个update耗时特别长，仔细一看就是昨天执行的delete操作，瞬间慌了。想着赶紧先停掉吧。
于是继续头脑发蒙，问gpt怎么停掉，gpt告诉我kill就行，于是我就执行了kill connectid，没想到脑残了。
继续查看sql连接，发现还是在执行中，只是变成了kill中，只能继续问gpt。

gpt告诉我mysql会回滚kill的连接操作。我瞬间炸毛了。跑了一晚上删除了一千万的数据，这kill一下，要全部回滚。疯了。

继续查询如何kill掉这个kill，然后gpt和网上很多说法是要修改回滚的设置，我一想算了，摆烂吧。线上只是卡慢，要是出问题就废了。

于是第三天，终于kill的链接没了。查了一下数据，还是很多，还得想办法。网上说了很多办法，复制表之类的，但是都有业务停顿。

仔细分析原因，上面的执行速度慢，其实是因为where条件慢，即使加了limit也不行，数据太大，每次where的执行效率太慢，于是乎突发奇想，不如直接delete xxx where id=xxx，试了一下，这样可以。
于是乎，因为id是自增的，我知道最大值，只需要生成删除脚本就可以了。生成了个删除三千万行的脚本，2G，zip压缩一下，100M，压缩效率真是高。

于是乎source 执行这个脚本，挺好的，没想到睡了一觉，发现没有后台执行，本以为是可以后台执行的。

继续查询，这个时候gpt不给力了。经常卡断。于是百度，nohup 吧，nohup说了后台执行，日志输出不太对，没当回事，因为上面mysql客户端执行的时候日志是正常的，于是nohup就执行了，没想到nohup之后，日志没有输出，听天由命吧。看了下mysql链接，已经不断的在删除数据了。
这样最起码不会回滚了。听天由命。

只是这样业务不中断。有好办法欢迎留言讨论。