MySQL删除数据的三种方式!!!(有超级大坑)
2023-03-14 09:35:20 时间
行数据批量delete时,InnoDB如何处理自增ID的?
这里有一个潜在的大坑。
整个实验步骤如上图:
- 第一步:建表,设定自增列;
- 第二步:指定id=1插入,锚定第一行是id是1;
- 第三步:不指定id,依赖自增机制,插入3行;画外音:此时id应该变为2,3,4了?
- 第四步:delete删除所有记录;画外音:坑就容易出在这里。
- 第五步:指定id=0插入;
- 第六步:指定id=1插入;
- 第七步:不指定id,依赖自增机制,插入1行;
请问,此时表中的三行记录,id分别是多少?
是否符合大家的预期?
今天花1分钟,说说使用truncate与delete批量删除数据的异同。
批量删除数据有三种常见的方法:
(1) drop table:当不需要该表时,可以使用该方法。
(2) truncate table:删除所有数据,同时保留表,速度很快。
画外音:可以理解为,drop table然后再create table。
(3) delete from table:可以删除所有数据,也能保留表,但性能较差。也可以带where条件删除部分数据,灵活性强。
虽然truncate和delete都能够删除所有数据,且保留表,但他们之间是有明显差异的。
(1)
- truncate是DDL语句,它不存在所谓的“事务回滚”;
- delete是DML语句,它执行完是可以rollback的。
(2)
- truncate table返回值是0;
- delete from table返回值是被删除的行数。
(3) InnoDB支持一个表一个文件,此时:
- truncate会一次性把表干掉,且不会激活触发器,速度非常快;
- delete from table则会一行一行删除,会激活触发器,速度比较慢。
画外音:delete数据,是要记录日志的,truncate表不需要记录日志。
(4) 当表中有列被其它表作为外键(foreign key)时:
- truncate会是失败;
- delete则会成功。
画外音:这类数据删除失败很容易定位问题,因为报错提示简单易懂。
(5) 当表中有自增列时:
- truncate会使得自增列计数复原;
- delete所有数据后,自增列计数并不会从头开始。
画外音:因此,delete所有数据后,自增列计数的这个行为,往往不是用户想要的,所以是一个潜在坑。
这一分钟,有收获吗?
请根据自己的业务场景,选择删除数据的方式哟。
相关文章
- 数据孤岛是业务效率的无声杀手
- 2023展望:新的一年将给大数据分析领域带来什么?
- 阿里云ADB基于Hudi构建Lakehouse的实践
- 大数据在医疗保健领域的使用案例
- 微软增加说明:KB5021751 更新扫描已经 / 即将过时 Office 过程中不会触碰用户隐私
- 2022 Gartner全球云数据库管理系统魔力象限发布 腾讯云数据库入选
- 场景化、重实操,分享一个实时数仓实践案例
- Arctic的湖仓一体践行之路
- 分布式计算MapReduce究竟是怎么一回事?
- 淘系数据模型治理优秀实践
- 大数据分析对医疗保健的影响
- 当我们说大数据Hadoop,究竟在说什么?
- 2022年及以后大数据的五个发展趋势
- 网易严选离线数仓治理实践
- 2023 年数据治理趋势
- 一份“靠谱”的年度经营计划,你学会了吗?
- 漫谈对大数据的思考
- 测试一下,读懂数据的能力,你有吗?
- 用艺术的眼光探索数据之美
- 聊聊数据分析成果如何落地