批量删除資料，常見的大坑！！！

行資料批量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所有資料後，自增列計數的這個行為，往往不是使用者想要的，是以是一個潛在坑。 這一分鐘，有收獲嗎？請根據自己的業務場景，選擇删除資料的方式喲。

本文轉自“架構師之路”公衆号，58沈劍提供。