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

SQL Serverデータベーステーブルにレコードを挿入しました。テーブルには主キーが定義されており、自動インクリメントIDシードは「はい」に設定されています。これは主に、SQL Azureでは、各テーブルに主キーとIDを定義する必要があるためです。

しかし、テーブルからいくつかのレコードを削除する必要があるため、それらのテーブルのIDシードが乱れ、インデックス列（1の増分で自動生成されます）が乱されます。

列を昇順の番号順にするためにレコードを削除した後、ID列をリセットするにはどうすればよいですか？

ID列は、データベースのどこでも外部キーとして使用されません。

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

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 Example Cは、同じページにある独自のものとも矛盾しています。

C.現在のID値を新しい値に強制する

次の例では、AddressTypeテーブルのAddressTypeID列の現在のID値を10の値に強制します。テーブルには既存の行があるため、挿入された次の行は値として11を使用します。つまり、列の値+ 1。

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

それでも、これはすべて、新しいSQL Serverバージョンでの異なる動作のオプションを残します。私が確信する唯一の方法は、Microsoftが自身のドキュメンテーションで物事を明確にするまでは、使用前に実際のテストを行うことだと思います。

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

ここで、0はidentity開始値です

IFことに留意すべき全てのデータが経由してテーブルから削除されているDELETE（すなわちノーWHEREであるように思われる（表を参照ないFKSが存在しない）、その後限り）アクセス許可が、aとbを可能にするように、句）ここでのケース）、TRUNCATE TABLEより効率的でDELETE ありIDENTITY、同時にシードをリセットするため、使用することをお勧めします 次の詳細は、TRUNCATE TABLEの MSDNページからの抜粋です。

DELETEステートメントと比較して、TRUNCATE TABLEには次の利点があります。

• 使用されるトランザクションログ領域が少なくなります。

  DELETEステートメントは、一度に1行ずつ削除し、削除された各行のエントリをトランザクションログに記録します。TRUNCATE TABLEは、テーブルデータの格納に使用されるデータページの割り当てを解除することでデータを削除し、ページの割り当て解除のみをトランザクションログに記録します。

• 通常、使用されるロックは少なくなります。

  行ロックを使用してDELETEステートメントを実行すると、テーブルの各行が削除のためにロックされます。TRUNCATE TABLEは常にテーブル（スキーマ（SCH-M）ロックを含む）とページをロックしますが、各行はロックしません。

• 例外なく、テーブルにはページが残りません。

  DELETEステートメントが実行された後も、テーブルに空のページが含まれることがあります。たとえば、ヒープ内の空のページは、少なくとも排他的な（LCK_M_X）テーブルロックがないと割り当て解除できません。削除操作でテーブルロックを使用しない場合、テーブル（ヒープ）には多くの空のページが含まれます。インデックスの場合、削除操作によって空のページが残る場合がありますが、これらのページはバックグラウンドのクリーンアッププロセスによってすばやく割り当て解除されます。

テーブルにID列が含まれている場合、その列のカウンターは、列に定義されているシード値にリセットされます。シードが定義されていない場合、デフォルト値1が使用されます。IDカウンターを保持するには、代わりにDELETEを使用します。

したがって、次のようになります。

DELETE FROM [MyTable];
DBCC CHECKIDENT ('[MyTable]', RESEED, 0);

ちょうどなる：

TRUNCATE TABLE [MyTable];

TRUNCATE TABLE制限事項などの詳細については、上記のリンクのドキュメントを参照してください。

ほとんどの回答はRESEEDを0に提案していますが、多くの場合、利用可能な次のIDに再シードする必要があります

declare @max int
select @max=max([Id])from [TestTable]
if @max IS NULL   //check when max is returned as null
  SET @max = 0
DBCC CHECKIDENT ('[TestTable]', RESEED,@max)

これにより、テーブルがチェックされ、次のIDにリセットされます。

私が@anil shahs答えてみたところ、IDがリセットされました。しかし、新しい行が挿入されたとき、それはを取得しましたidentity = 2。代わりに、構文を次のように変更しました：

DELETE FROM [TestTable]

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

次に、最初の行はID = 1を取得します。

ほとんどの回答はに示唆RESEEDしていますが0、一部の回答ではこれをTRUNCATEDテーブルの欠陥と見なしていますが、Microsoftには、ID

DBCC CHECKIDENT ('[TestTable]', RESEED)

これにより、テーブルがチェックされ、次のテーブルにリセットされIDます。これは、MS SQL 2005から現在まで利用可能です。

https://msdn.microsoft.com/en-us/library/ms176057.aspx

2つのコマンドを発行すると、トリックを行うことができます

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

最初はIDをゼロにリセットし、次はIDを次に使用可能な値に設定します-jacob

@jacob

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

私のために働いた、私は最初にすべてのエントリをテーブルからクリアする必要があり、それから削除後のトリガーポイントに上記を追加した。今、私はエントリを削除するたびにそこから取得されます。

Truncate テーブルは、レコードをクリアし、カウンターをリセットし、ディスク領域を再利用するため、推奨されます。

DeleteまたCheckIdent、外部キーによって切り捨てられない場合にのみ使用してください。

ID列を新しいIDでリセット...

DECLARE @MAX INT
SELECT @MAX=ISNULL(MAX(Id),0) FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED,@MAX)

これは一般的な質問であり、答えは常に同じです：しないでください。ID値は任意として扱う必要があるため、「正しい」順序はありません。

このスクリプトを実行してID列をリセットします。2つの変更を行う必要があります。tableXYZを、更新する必要のある任意のテーブルに置き換えます。また、ID列の名前を一時テーブルから削除する必要があります。これは、35,000行＆3列のテーブルで瞬時に発生しました。明らかに、テーブルをバックアップし、最初にこれをテスト環境で試します。

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

DBCC CHECKIDENT (<TableName>, reseed, 0)

これにより、現在のID値が0に設定されます。

次の値を挿入すると、ID値が1に増加します。

このストアドプロシージャを使用します。

IF (object_id('[dbo].[pResetIdentityField]') IS NULL)
  BEGIN
    EXEC('CREATE PROCEDURE [dbo].[pResetIdentityField] AS SELECT 1 FROM DUMMY');
  END
GO

SET  ANSI_NULLS ON
GO
SET  QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[pResetIdentityField]
  @pSchemaName NVARCHAR(1000)
, @pTableName NVARCHAR(1000) AS
DECLARE @max   INT;
DECLARE @fullTableName   NVARCHAR(2000) = @pSchemaName + '.' + @pTableName;

DECLARE @identityColumn   NVARCHAR(1000);

SELECT @identityColumn = c.[name]
FROM sys.tables t
     INNER JOIN sys.schemas s ON t.[schema_id] = s.[schema_id]
     INNER JOIN sys.columns c ON c.[object_id] = t.[object_id]
WHERE     c.is_identity = 1
      AND t.name = @pTableName
      AND s.[name] = @pSchemaName

IF @identityColumn IS NULL
  BEGIN
    RAISERROR(
      'One of the following is true: 1. the table you specified doesn''t have an identity field, 2. you specified an invalid schema, 3. you specified an invalid table'
    , 16
    , 1);
    RETURN;
  END;

DECLARE @sqlString   NVARCHAR(MAX) = N'SELECT @maxOut = max(' + @identityColumn + ') FROM ' + @fullTableName;

EXECUTE sp_executesql @stmt = @sqlString, @params = N'@maxOut int OUTPUT', @maxOut = @max OUTPUT

IF @max IS NULL
  SET @max = 0

print(@max)

DBCC CHECKIDENT (@fullTableName, RESEED, @max)
go

--exec pResetIdentityField 'dbo', 'Table'

ちょうど私の答えを再訪します。SQL Server 2008 R2で気が付くべき奇妙な動作に遭遇しました。

drop table test01

create table test01 (Id int identity(1,1), descr nvarchar(10))

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

delete from test01

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

最初の選択はを生成し0, Item 1ます。

2つ目はを生成し1, Item 1ます。テーブルが作成された直後にリセットを実行すると、次の値は0になります。正直なところ、Microsoftがこれを正しく行えないことに驚いていません。テーブルを再作成した後で実行したり、テーブルが既に作成されているときに実行したりする参照テーブルを作成するスクリプトファイルがあるので、それを発見しました。

これを行うには、次のスクリプトを使用します。「エラー」が発生するシナリオは1つだけですIDENT_CURRENT。つまり、テーブルからすべての行を削除し、現在1に設定されている場合です。つまり、最初はテーブルに1行しかありませんでした。

DECLARE @maxID int = (SELECT MAX(ID) FROM dbo.Tbl)
;

IF @maxID IS NULL
    IF (SELECT IDENT_CURRENT('dbo.Tbl')) > 1
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 0)
    ELSE
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 1)
    ;
ELSE
    DBCC CHECKIDENT ('dbo.Tbl', RESEED, @maxID)
;

完全なDELETE行とIDENTITYカウントをリセットするには、これを使用します（SQL Server 2008 R2）

USE mydb

-- ##################################################################################################################
-- DANGEROUS!!!! USE WITH CARE
-- ##################################################################################################################

DECLARE
  db_cursor CURSOR FOR
    SELECT TABLE_NAME
      FROM INFORMATION_SCHEMA.TABLES
     WHERE TABLE_TYPE = 'BASE TABLE'
       AND TABLE_CATALOG = 'mydb'

DECLARE @tblname VARCHAR(50)
SET @tblname = ''

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @tblname

WHILE @@FETCH_STATUS = 0
BEGIN
  IF CHARINDEX('mycommonwordforalltablesIwanttodothisto', @tblname) > 0
    BEGIN
      EXEC('DELETE FROM ' + @tblname)
      DBCC CHECKIDENT (@tblname, RESEED, 0)
    END

  FETCH NEXT FROM db_cursor INTO @tblname
END

CLOSE db_cursor
DEALLOCATE db_cursor
GO

テーブル全体をクリーンアップしない限り、0への再シードはあまり実用的ではありません。

そうでなければ、Anthony Raymondの答えは完璧です。最初にID列の最大値を取得してから、最大値をシードします。

私は開発中に多数のテーブルに対してこれを実行するように努めてきましたが、これは魅力的に機能します。

DBCC CHECKIDENT('www.newsType', RESEED, 1);
DBCC CHECKIDENT('www.newsType', RESEED);

したがって、最初に強制的に1に設定し、次にテーブルに存在する行の最高のインデックスに設定します。idexの残りの部分はすばやく簡単です。

ログスペースも使用しないため、すべてのレコードを削除するのではなく、可能な場合は常にTRUNCATEを使用することをお 勧めします。

削除が必要でシードをリセットする必要がある場合は、テーブルにデータが入力されておらず、使用したDBCC CHECKIDENT('tablenem',RESEED,0) 場合、msdnのドキュメントに記載されているように、最初のレコードはID = 0になることに注意して ください。

あなたのケースでは、インデックスを再構築するだけであり、これは一般的なシナリオであるため、一連のIDを失う心配はありません。

最初：ID仕様Just： "いいえ" >>データベースの保存プロジェクトの実行

その後：Identity Specification Just： "YES" >>データベースの保存プロジェクトの実行

データベースID、PK 1から開始>>