本文翻譯自：Reset identity seed after deleting records in SQL Server
I have inserted records into a SQL Server database table. 我已將記錄插入SQL Server數據庫表。 The table had a primary key defined and the auto increment identity seed is set to “Yes”. 該表定義了主鍵，並且自動增量標識種子設置爲“是”。 This is done primarily because in SQL Azure, each table has to have a primary key and identity defined. 這主要是因爲在SQL Azure中，每個表都必須定義主鍵和標識。
But since I have to delete some records from the table, the identity seed for those tables will be disturbed and the index column (which is auto-generated with an increment of 1) will get disturbed. 但由於我必須從表中刪除一些記錄，這些表的標識種子將受到干擾，並且索引列（自動生成的增量爲1）將受到干擾。
How can I reset the identity column after I deleted the records so that the column has sequence in ascending numerical order? 刪除記錄後，如何重置標識列，以使列按數字順序遞增？
The identity column is not used as a foreign key anywhere in database. 標識列不用作數據庫中任何位置的外鍵。
#1樓
參考：https://stackoom.com/question/1TZXi/刪除SQL-Server中的記錄後重置標識種子
#2樓
DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO
Where 0 is identity Start value 其中0是identity起始值
#3樓
The DBCC CHECKIDENT management command is used to reset identity counter. DBCC CHECKIDENT管理命令用於重置身份計數器。 The command syntax is: 命令語法是：
DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]
Example: 例：
DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO
It was not supported in a previous versions of Azure SQL Database, but is supported now. 以前版本的Azure SQL數據庫不支持它，但現在支持。
Please note that new_reseed_value argument is varied across SQL Server versions according to documentation : 請注意， 根據文檔 ， new_reseed_value參數在SQL Server版本中是不同的：
If rows are present in the table, the next row is inserted with the new_reseed_value value. 如果表中存在行，則使用new_reseed_value值插入下一行。 In version SQL Server 2008 R2 and earlier, the next row inserted uses new_reseed_value + the current increment value. 在SQL Server 2008 R2及更早版本中，插入的下一行使用new_reseed_value +當前增量值。
However, I find this information misleading (just plain wrong actually) because observed behaviour indicates that at least SQL Server 2012 is still uses new_reseed_value + the current increment value logic. 但是， 我發現這些信息具有誤導性 （實際上只是錯誤的），因爲觀察到的行爲表明至少SQL Server 2012仍然使用new_reseed_value +當前的增量值邏輯。 Microsoft even contradicts with its own Example C found on same page: 微軟甚至與在同一頁面上找到的自己的Example C相矛盾：
C. Forcing the current identity value to a new value C.將當前標識值強制爲新值
The following example forces the current identity value in the AddressTypeID column in the AddressType table to a value of 10. Because the table has existing rows, the next row inserted will use 11 as the value, that is, the new current increment value defined for the column value plus 1. 以下示例強制將AddressType表中的AddressTypeID列中的當前標識值設置爲10.因爲該表具有現有行，所以插入的下一行將使用11作爲值，即，爲其定義的新當前增量值列值加1。
USE AdventureWorks2012;
GO
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO
Still, this all leaves an option for different behaviour on newer SQL Server versions. 儘管如此，這都爲新的SQL Server版本留下了不同行爲的選項。 I guess the only way to be sure, until Microsoft clear up things in its own documentation, is to do actual tests before usage. 我想在確保微軟在自己的文檔中清理內容之前，唯一可以確定的方法是在使用前進行實際測試。
#4樓
This is a common question and the answer is always the same: don't do it. 這是一個常見的問題，答案總是一樣的：不要這樣做。 Identity values should be treated as arbitrary and, as such, there is no "correct" order. 身份值應被視爲任意，因此，沒有“正確”的順序。
#5樓
I tried @anil shahs answer and it reset the identity. 我嘗試了@anil shahs答案並重置了身份。 But when a new row was inserted it got the identity = 2 . 但是當插入新行時，它獲得了identity = 2 。 So instead I changed the syntax to: 所以我改爲將語法改爲：
DELETE FROM [TestTable]
DBCC CHECKIDENT ('[TestTable]', RESEED, 0)
GO
Then the first row will get the identity = 1. 然後第一行將獲得identity = 1。
#6樓
Run this script to reset the identity column. 運行此腳本以重置標識列。 You will need to make two changes. 您需要進行兩項更改。 Replace tableXYZ with whatever table you need to update. 將tableXYZ替換爲您需要更新的任何表。 Also, the name of the identity column needs dropped from the temp table. 此外，需要從臨時表中刪除標識列的名稱。 This was instantaneous on a table with 35,000 rows & 3 columns. 這是在一個有35,000行和3列的桌子上的瞬間。 Obviously, backup the table and first try this in a test environment. 顯然，備份表並首先在測試環境中嘗試此操作。
select *
into #temp
From tableXYZ
set identity_insert tableXYZ ON
truncate table tableXYZ
alter table #temp drop column (nameOfIdentityColumn)
set identity_insert tableXYZ OFF
insert into tableXYZ
select * from #temp