ITPub博客

首页博客专栏学院社区 IT新媒体评选

发博

首页 > > > 批量删除数据，常见的大坑！！！

批量删除数据，常见的大坑！！！

作者：58沈剑时间：2020-01-02 11:09:26 0 删除编辑

行数据批量delete时，InnoDB如何处理自增ID，是一个潜在的大坑。

整个实验步骤如上图：

第一步：建表，设定自增列；

第二步：指定id=1插入，锚定第一行是id是1；

第三步：不指定id，依赖自增机制，插入3行；

画外音：此时id应该变为2，3，4了？

第四步：delete删除所有记录；

画外音：坑就容易出在这里。

第五步：指定id=0插入；

第六步：指定id=1插入；

第七步：不指定id，依赖自增机制，插入1行；

请问，此时表中的三行记录，id分别是多少？

是否符合大家的预期？

今天花1分钟，说说使用truncate与delete批量删除数据的异同。

批量删除数据有三种常见的方法

drop table

当不需要该表时，可以使用该方法。

truncate table

删除所有数据，同时保留表，速度很快。

画外音：可以理解为，drop table然后再create table。

delete from table

可以删除所有数据，也能保留表，但性能较差。

也可以带where条件删除部分数据，灵活性强。

虽然truncate和delete都能够删除所有数据，且保留表，但他们之间是有明显差异的。

一、

truncate是DDL语句，它不存在所谓的“事务回滚”；

delete是DML语句，它执行完是可以rollback的。

二、

truncate table返回值是0；

delete from table返回值是被删除的行数。

三、

InnoDB支持一个表一个文件，此时：

truncate会一次性把表干掉，且不会激活触发器，速度非常快；

delete from table则会一行一行删除，会激活触发器，速度比较慢。

画外音：delete数据，是要记录日志的，truncate表不需要记录日志。

四、

当表中有列被其它表作为外键(foreign key)时：

truncate会是失败；

delete则会成功。

画外音：这类数据删除失败很容易定位问题，因为报错提示简单易懂。

五、

当表中有自增列是：

truncate会使得自增列计数复原；

delete所有数据后，自增列计数并不会从头开始。

画外音：因此，delete所有数据后，自增列计数的这个行为，往往不是用户想要的，所以是一个潜在坑。

这一分钟，有收获吗？

请根据自己的业务场景，选择删除数据的方式哟。

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31556838/viewspace-3148165/ ，如需转载，请注明出处，否则将追究法律责任。

上一篇：分布式基础，通俗易懂CAP？

下一篇：互联网分层架构的本质

请登录后发表评论登录

全部评论

专家姓名：沈剑

58速运CTO，互联网架构技术专家，“架构师之路”公众号作者。曾任百度高级工程师，58同城技术委员会主席，高级架构师，58到家技术委员会主席，高级技术总监，目前主要负责58速运技术部。

注册时间：2018-09-30

博文量
420
访问量

82617

最新文章

北京盛拓优讯信息技术有限公司. 版权所有京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号中国互联网协会会员

违法和不良信息举报电话:18101376593