MySQL 9.0 版本資訊
TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE 會完全清空資料表。它需要 DROP 權限。邏輯上，TRUNCATE TABLE 類似於刪除所有資料列的 DELETE 陳述式，或是 DROP TABLE 和 CREATE TABLE 陳述式的序列。
為了達到高效能，TRUNCATE TABLE 會繞過使用 DML 方法刪除資料。因此，它不會觸發 ON DELETE 觸發器，對於具有父子外鍵關係的 InnoDB 資料表，它無法執行，也無法像 DML 操作一樣回滾。然而，對於使用支援原子 DDL 的儲存引擎的資料表，TRUNCATE TABLE 操作若在操作期間伺服器停止，則會完全提交或回滾。如需更多資訊，請參閱第 15.1.1 節，「原子資料定義語句支援」。
雖然 TRUNCATE TABLE 類似於 DELETE，但它被歸類為 DDL 語句而不是 DML 語句。它與 DELETE 的不同之處在於以下幾點：
截斷操作會刪除並重新建立資料表，這比逐一刪除列要快得多，特別是對於大型資料表。
截斷操作會導致隱式提交，因此無法回滾。請參閱第 15.3.3 節，「導致隱式提交的語句」。
如果會話持有活動的資料表鎖定，則無法執行截斷操作。
如果其他資料表有任何參考該資料表的
FOREIGN KEY限制，TRUNCATE TABLE對於InnoDB資料表或NDB資料表會失敗。允許在同一資料表的欄位之間存在外鍵限制。截斷操作不會傳回已刪除列數的有意義的值。通常的結果是 「0 rows affected (0 列受影響)」，這應該被解釋為 「no information (沒有資訊)」。
只要資料表定義有效，即使資料或索引檔案已損毀，也可以使用
TRUNCATE TABLE將資料表重新建立為空資料表。任何
AUTO_INCREMENT值都會重設為其起始值。即使對於通常不重複使用序列值的MyISAM和InnoDB，也是如此。當與分割資料表一起使用時，
TRUNCATE TABLE會保留分割；也就是說，會刪除並重新建立資料和索引檔案，而分割定義不受影響。TRUNCATE TABLE語句不會呼叫ON DELETE觸發器。支援截斷損毀的
InnoDB資料表。
為了二進位日誌記錄和複寫的目的，TRUNCATE TABLE 被視為 DDL 而非 DML，並且總是作為語句記錄。
對於使用 HANDLER OPEN 開啟的資料表，TRUNCATE TABLE 會關閉該資料表的所有處理常式。
TRUNCATE TABLE 可以與效能結構描述摘要資料表一起使用，但效果是將摘要欄位重設為 0 或 NULL，而不是移除列。請參閱第 29.12.20 節，「效能結構描述摘要資料表」。
截斷位於每個資料表空間檔案中的 InnoDB 資料表會刪除現有的資料表空間並建立一個新的資料表空間。如果資料表空間是使用較早的版本建立的，並且位於未知的目錄中，InnoDB 會在預設位置建立新的資料表空間，並在錯誤日誌中寫入以下警告：The DATA DIRECTORY location must be in a known directory. The DATA DIRECTORY location will be ignored and the file will be put into the default datadir location (DATA DIRECTORY 位置必須位於已知的目錄中。DATA DIRECTORY 位置將被忽略，檔案將被放置在預設的 datadir 位置)。 已知的目錄是透過 datadir、innodb_data_home_dir 和 innodb_directories 變數所定義的目錄。若要讓 TRUNCATE TABLE 在其目前位置建立資料表空間，請在執行 TRUNCATE TABLE 之前，將目錄新增至 innodb_directories 設定中。