去掉limit，可能要精确到每分钟了。 
，我写脚本时间还没执行时间快呢。
删除的时候看过慢查询里的执行计划么？能看到哪一步慢么？另外执行删除的时候IO\CPU\内存状况怎么样？如果没有满载，我觉得可以开两个线程一起删。
如果是周期性的需求建议改造成分区表
1 个赞
这样靠不靠谱？就是新建一个表，列是待删除表的主键列，然后按照日期将主键数据插入到这个表，然后删除的时候根据这个表去删除，这样是不是就相当于主键列删除，并且没有limit的影响。
，恩可以试试。之前有这么想过，但是需要把主键全部查出来放在表里面，比我直接拼接delete sql多一个步骤，就没去做。 
不是全部查出来，是只把要本批次要删除日期内的查出来。其实也是分段。
刚查出来插入到一个临时表试了一下，一天几百万，数据量太大，只能1天分成四五批。这样搞得话，太麻烦了
要删除4年的数据呢，这样搞一年365天，每天还要再分成5批。累死人咯
INSERT INTO tmp_001 select out_park_order_id from report_prod.out_park_order_report where out_dt>=‘20200101210000’ and out_dt<=‘20200101235959’;
delete from report_prod.out_park_order_report where out_park_order_id in (select out_park_order_id from tmp_001) limit 10000;
改成这样呢？
delete from report_prod.out_park_order_report
where out_park_order_id in (select out_park_order_id from tmp_001 limit 10000);
浏览了下帖子，很极限的操作。在不能增加存储的情况下就还是慢慢执行delete操作吧。常规操作是通过调度新表drop旧表。
这样的话，那会不会001 里面limit的10000 数据有一部分其实已经删除了呢。
恩。目前是慢慢删除。
每次删完 001这个临时表里的数据也要清。主要是为了把limit放到小表上。楼上不是有位大佬说limit在低版本有性能问题嘛
对说是因为删除多了mvcc数据太多。后面删除就会越来越慢。
但是按你的意思。001则这个表几百或者上千万的主键也要同步删除？001临时表如果实际操作的话。至少放1个月的 六千万左右。每次limit1w 这个001 取出1w去删除主表。删除之后。001表这对应的1w没有删除呀。
如果GC正常，就不会有这个影响。如果GC没有清理已删除的数据，查询的时候会因为扫描已删除的数据而导致越来越慢。v4这个版本，当时真的是痛并快乐着。
1 个赞
对目前删除几个月了。大表从40s到2.5分钟。最多就是2.5分钟。这个可能就是删除数据过多版本数量最多，一个执行的时间极限了。目前只能这样慢慢执行了。根据主键删除用子查询我上面发的按个sql，速度比这个直接日期还慢一点
好吧，那还是只能慢慢删了。
重建表是不是更快一些，可以测试一下，v4版本是不是可以升级了 