标签:回滚 缓冲 开始 数据 因此 思路 保留 返回 run
行数据批量delete时,InnoDB如何处理自增ID,是一个潜在的大坑。是否符合大家的预期?
今天花1分钟,说说使用truncate与delete批量删除数据的异同。
批量删除数据有三种常见的方法
当不需要该表时,可以使用该方法。
删除所有数据,同时保留表,速度很快。
画外音:可以理解为,drop table然后再create 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所有数据后,自增列计数的这个行为,往往不是用户想要的,所以是一个潜在坑。
这一分钟,有收获吗?
请根据自己的业务场景,选择删除数据的方式哟。
架构师之路-分享技术思路
《缓冲池(buffer pool)》
《写缓冲(change buffer)》
《日志缓冲(log buffer)》
开头的实验,最后表中的三行记录,id分别是多少?
画外音:你以为文章告诉了你原理,你就能答对么。
标签:回滚 缓冲 开始 数据 因此 思路 保留 返回 run
原文地址:https://blog.51cto.com/jyjstack/2547996