【紧急求助】生产环境 TIDB DROP删除一个12T的大表对业务有没有影响？

苏半生Su · 2023 年11 月 9 日 02:25

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.4
drop table一个12T的大表，对业务有没有影响？
有没有类似MYSQL大表drop使用硬链接的方式删除的？

TiDBer_小阿飞 · 2023 年11 月 9 日 02:32

肯定有影响的，因为有GC机制和MVCC

如果你需要删除大量行（数万或更多）的时候，建议使用一个迭代，每次都只删除一部分数据，直到删除全部完成。这是因为 TiDB 单个事务大小限制为 txn-total-size-limit（默认为 100MB）。你可以在程序或脚本中使用循环来完成操作。

像风一样的男子 · 2023 年11 月 9 日 02:33

delete删除12T数据，疯了么，这么干数据库波动才大

h5n1 · 2023 年11 月 9 日 02:34

drop操作。达到GC时间后会清理sst 文件，可能引起一定IO，之后会有大量的空region，pd会调度region合并消耗些资源。整体影响不大

像风一样的男子 · 2023 年11 月 9 日 02:34

理论上是没影响，建议业务低谷期drop

路在何chu · 2023 年11 月 9 日 02:35

他是drop

TiDBer_小阿飞 · 2023 年11 月 9 日 02:35

像风一样的男子 · 2023 年11 月 9 日 02:35

我回复的楼上那个建议delete删除那个

扬仔_tidb · 2023 年11 月 9 日 02:37

必须要做的事，肯定要做。放低峰期执行。但是对tikv执行GC会有性能影响

路在何chu · 2023 年11 月 9 日 02:38

tidb.drop和truncate应该那啥区别吧

TiDBer_小阿飞 · 2023 年11 月 9 日 02:43

那不还有非事务 DML 嘛

随缘天空 · 2023 年11 月 9 日 02:48

不建议一次性执行这么大的操作，可以弄个定时器每天凌晨固定时间多线程异步删除，等数据量下来后在执行truncate table操作

随缘天空 · 2023 年11 月 9 日 02:52

应该有影响，删除表和里面的数据，毕竟需要占用cpu和内存资源

苏半生Su · 2023 年11 月 9 日 03:02

是drop table的删除

苏半生Su · 2023 年11 月 9 日 03:05

drop table表，不用delete。这样是不是也会gc和io卡死？

像风一样的男子 · 2023 年11 月 9 日 03:07

在执行DROP TABLE操作时，会有大量连续的数据被删除。tidb会将这些待删除的区间及删除操作的时间戳记录下来，并不会立即物理删除。gc阶段：Delete Ranges 会将这些时间戳在 safe point 之前的区间进行快速的物理删除。物理删除主要是消耗磁盘io，对cpu内存影响较小

苏半生Su · 2023 年11 月 9 日 03:10

drop是磁盘IO的一下子拉高，还是缓慢慢的drop。如果IO直接100%，那业务不就gg了吗？

像风一样的男子 · 2023 年11 月 9 日 03:12

我只drop过一百多亿行记录的表没啥影响，你这12t数据量太大了，没有人干过，不敢给你打包票，所以建议你业务低谷期干。

zhanggame1 · 2023 年11 月 9 日 03:36

这么删一年都删不完。不信你测试下，1亿数据，开始删超级快，后面越来越慢，从几十毫秒一直到几秒一次

zhanggame1 · 2023 年11 月 9 日 03:39

强烈不建议delete数据，tidb 的持续delete性能非常差，会越来越慢，而且硬盘数据量会激增，分分钟把硬盘写爆了