行数据批量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的。

,

以太坊开奖

www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。

,

二、

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划分是若干?
画外音:你以为文章告诉了你原理,你就能答对么。