2小时的SQL操作，1分钟就搞定？

　　今天来讲讲关于大表删除的问题。
　　比如，你现在需要删除一张一共有5亿数据的表里面的2021年数据，假设这张表叫yes。
　　我相信你脑子在1s内肯定会蹦出这条SQL：deletefromyeswherecreatedate20201231andcreatedate20220101；
　　如果直接执行这条SQL会发生什么问题呢？长事务
　　我们需要关注到一个前提：这张表有5亿的数据，所以它是一张超大表，因此这个where条件可能涉及非常多的数据，所以我们可以从离线数仓或者备库查下数据量，然后我们发现这条SQL会删除3亿左右的数据。
　　那么一次性delete完的方案是不行的，因为这会涉及到长事务的问题。
　　长事务涉及到加锁，只会在事务执行完毕后才会释放锁，由于长事务锁了很多数据，如果期间有频繁的DML想要操作这些数据，那么就会造成阻塞。
　　连接都阻塞住了，业务线程自然就阻塞了，也就是说你的服务线程都在等待数据库的响应，然后可能还会影响到别的服务，可能产生雪崩，于是就GG了。
　　长事务可能会造成主从延迟，你想想主库执行了好久，才执行完给从库，从库又要重放好久，期间可能有很长一段时间数据是不同步的。
　　还有一种情况，业务都有个特殊停机窗口，你觉得你可以为所欲为，然后开始执行长事务了，然后执行了5小时之后，不知道啥情况抛错了，事务回滚了，于是浪费了5个小时，还得重新开始。
　　综上，我们需要避免长事务的发生。
　　那面对可能发生长事务的SQL我们怎么拆呢？拆SQL
　　我们就以上面这条SQL为例：deletefromyeswherecreatedate20201231andcreatedate20220101；
　　看到这条SQL，如果要拆分，想必很多小伙伴会觉得很简单，按日期拆不就完事了？deletefromyeswherecreatedate20201231andcreatedate20210201；deletefromyeswherecreatedate20210201andcreatedate20210301；
　　这当然可以，恭喜你，你已经拆分成功了，没错就这么简单。
　　但是，如果createdate没有索引怎么办？
　　没索引的话，上面这就全表扫描了啊？
　　影响不大，没有索引我们就给他创造索引条件，这个条件就是主键。
　　我们直接一个selectmin（id）。。。和selectmax（id）。。。。得到这张表的主键最小值和最大值，假设答案是233333333和666666666。
　　然后我们就可以开始操作了：deletefromyeswhere（id233333333andid233433333）andcreatedate20201231andcreatedate20220101；deletefromyeswhere（id233433333andid233533333）andcreatedate20201231andcreatedate20220101；deletefromyeswhere（id666566666andid666666666）andcreatedate20201231andcreatedate20220101；
　　当然你也可以再精确些，通过日期筛选来得到maxId，这影响不大（不满足条件的SQL执行很快，不会耗费很多时间）。
　　这样一来SQL就满足了分批的操作，且用得上索引。
　　如果哪条语句执行出错，只会回滚小部分数据，我们重新排查下就好了，影响不大。
　　而且拆分SQL之后还可以并行提高执行效率。
　　当然，并行可能有锁竞争的情况，导致个别语句等待超时。不过影响不大，只要机器状态好，执行得快，因为锁竞争导致的等待并不一定会超时，如果个别SQL超时的话，重新执行就好了。有时候要转换思路
　　关于大表删除有时候要转换思路，把删除转成插入。
　　假设还是有一张5亿的数据表，此时你需要删除里面4。8亿的数据，那这时候就不要想着删除了，要想着插入。
　　道理很简单，删除4。8亿的数据，不如把要的2000W插入到新表中，我们后面业务直接用新表就好了。
　　这两个数据量对比，时间效率差异不言而喻了吧？
　　具体操作也简单：创建一张新表，名为yestemp；将yes表的2000W数据selectinto到yestemp中；将yes表rename成yes233；将yestemp表rename成yes。
　　狸猫换太子，大功告成啦！
　　之前有个记录表我们就是这样操作的，就selectinto近一个月的数据到新表中，以前老数据就不管了，然后rename一下，执行得非常快。
　　本来预估2小时的SQL操作，1分钟就搞定了。