行数据批量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划分是若干？
画外音：你以为文章告诉了你原理，你就能答对么。