SQL Serverでレコードを削除した後にIDシードをリセットする

IDカウンタをリセットするには、DBCC CHECKIDENT`管理コマンドを使用します。コマンドの構文は次のとおりです。

DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]

例を示します。

DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO

以前のバージョンのAzure SQL Databaseではサポートされていませんでしたが、現在はサポートされています。

なお、new_reseed_valueという引数は、SQL Serverのバージョンによって異なりますドキュメントによると。

テーブルに行が存在する場合、次の行は new_reseed_value の値で挿入されます。SQL Server 2008 R2以前のバージョンでは、次の行の挿入には new_reseed_value + 現在の増分値が使用されます。

しかし、この情報は誤解を招く恐れがあります*（実際には間違っています）。なぜなら、観察された動作は、少なくともSQL Server 2012がまだnew_reseed_value* + 現在の増分値のロジックを使用していることを示しているからです。Microsoftは、同じページにある独自の「サンプルC」でさえも矛盾しています。

C. 現在の ID 値を強制的に新しい値に変更する となっています。 次の例では、AddressTypeID列の現在のID値を強制的に新しい値に変更します。 以下の例では、AddressTypeテーブルのAddressTypeIDカラムの現在のID値を強制的に10にしています。 テーブルには既存の行があるため、次に挿入される行では11 つまり、列の値に定義された新しい現在の増分値に1を加えた値となります。 列の値に1を加えた値となります。

USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);  
GO

しかし、これでは新しいSQL Serverのバージョンでは異なる動作をする可能性があります。確信を持つための唯一の方法は、Microsoftが自社のドキュメントで物事を明確にするまでは、使用前に実際のテストを行うことだと思います。

DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

0 は identity 開始値

これはよくある質問ですが、答えはいつも同じで「やらない」です。ID値は任意のものとして扱われるべきであり、そのため、正しい順序というものはありません。