SQL Server TRUNCATE TABLE 是否會重置身分識別欄位種子值？

前言

在日常資料庫維護中，TRUNCATE TABLE 常被用來快速清空大量資料。但許多 DBA 心中都有個疑慮：執行 TRUNCATE TABLE 後，資料表的身分識別欄位種子值會不會重置？本文透過實際案例與測試，詳細說明其行為，並探討分區表情境下的相關影響。

案例背景：兩張 200GB 的分區表

某業務資料庫有兩張結構幾乎相同的分區表，單表大小約 200 GB，皆擁有自增 ID（身分識別欄位）。當時開發人員建議使用 TRUNCATE TABLE 清空資料。執行截斷後，因事務繁忙，未即時執行資料庫收縮與種子值重置。分區函數的最後一個邊界值為 2,000,000，若不重置種子，新插入資料將全數湧入最後一個檔案群，造成 I/O 熱點。

解決方案比較

• 方案一：重置種子值，讓資料重新利用第一個檔案群，工作量最小。
• 方案二：修改分區方案，使用 SPLIT RANGE 向分區函數新增邊界值，工作量較大。

為避免額外維護成本，選擇方案一較為划算。

實測驗證：TRUNCATE TABLE 確實會重置種子

下班後遠端連線檢查分區狀態，發現新插入資料確實落在第一個檔案群，且自增 ID 從 1 重新開始。隨即撰寫測試腳本驗證：

USE [test];
GO
CREATE TABLE truncatetabletestidentity (id INT IDENTITY(1,1), NAME NVARCHAR(20));
GO
INSERT [dbo].[truncatetabletestidentity] SELECT 'ni' UNION ALL SELECT 'we' UNION ALL SELECT 'pp';
SELECT * FROM [dbo].[truncatetabletestidentity];
GO
TRUNCATE TABLE [dbo].[truncatetabletestidentity];

測試結果證實：TRUNCATE TABLE 會將身分識別種子值重置為初始值（預設為 1）。

後續處理與收穫

執行 DBCC SHRINKDATABASE 釋放空間，磁碟瞬間「多出」 450 GB，磁碟預警解除。補充說明：MSDN 文件 DBCC CHECKIDENT 亦明確指出 TRUNCATE TABLE 會重置身分識別計數器。