Сбросить семя идентификации после удаления записей в SQL Server

Я вставил записи в таблицу базы данных SQL Server. Для таблицы был определен первичный ключ, и для начального идентификатора с автоприращением установлено значение «Да». Это делается главным образом потому, что в SQL Azure для каждой таблицы должны быть определены первичный ключ и идентификатор.

Но поскольку мне нужно удалить некоторые записи из таблицы, начальное число идентификаторов для этих таблиц будет нарушено, а столбец индекса (который создается автоматически с шагом 1) будет нарушен.

Как я могу сбросить столбец идентификаторов после удаления записей, чтобы столбец имел последовательность в порядке возрастания номеров?

Столбец идентификации не используется в качестве внешнего ключа в базе данных.

Команда DBCC CHECKIDENTуправления используется для сброса счетчика идентификаторов. Синтаксис команды:

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

Пример:

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

Это не поддерживалось в предыдущих версиях базы данных SQL Azure, но теперь поддерживается.

Обратите внимание, что 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. Принуждение текущего значения идентичности к новому значению

В следующем примере значение текущего идентификатора в столбце AddressTypeID в таблице AddressType устанавливается равным 10. Поскольку в таблице есть существующие строки, в следующей вставленной строке в качестве значения будет использоваться 11, то есть новое текущее значение приращения, определенное для значение столбца плюс 1.

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

Тем не менее, все это оставляет возможность для другого поведения в новых версиях SQL Server. Я предполагаю, что единственный способ быть уверенным, пока Microsoft не прояснит ситуацию в своей собственной документации, это сделать реальные тесты перед использованием.

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

Где 0 - identityначальное значение

Следует отметить, что ЕСЛИ все данные удаляются из таблицы через DELETE(то есть без WHEREпредложения), то, если это разрешено разрешениями a), и b) отсутствуют FK, ссылающиеся на таблицу (которая, по-видимому, является случай здесь), использование TRUNCATE TABLEбыло бы предпочтительным, так как это делает более эффективным DELETE и сбрасывает IDENTITYсемя в то же время. Следующие подробности взяты со страницы MSDN для TRUNCATE TABLE :

По сравнению с оператором DELETE TRUNCATE TABLE имеет следующие преимущества:

• Меньше места в журнале транзакций.

  Оператор DELETE удаляет строки по одной за раз и записывает запись в журнал транзакций для каждой удаленной строки. TRUNCATE TABLE удаляет данные, освобождая страницы данных, используемые для хранения данных таблицы, и записывает только освобождения страниц в журнал транзакций.

• Обычно используется меньше замков.

  Когда оператор DELETE выполняется с использованием блокировки строк, каждая строка в таблице блокируется для удаления. TRUNCATE TABLE всегда блокирует таблицу (включая блокировку схемы (SCH-M)) и страницу, но не каждую строку.

• Все без исключения нулевые страницы остаются в таблице.

  После выполнения оператора DELETE таблица все еще может содержать пустые страницы. Например, пустые страницы в куче не могут быть освобождены без хотя бы исключительной (LCK_M_X) блокировки таблицы. Если операция удаления не использует блокировку таблицы, таблица (куча) будет содержать много пустых страниц. Для индексов операция удаления может оставить пустые страницы позади, хотя эти страницы будут быстро освобождены в процессе фоновой очистки.

Если таблица содержит столбец идентификаторов, счетчик для этого столбца сбрасывается на начальное значение, определенное для столбца. Если начальное число не было определено, используется значение по умолчанию 1. Чтобы сохранить счетчик идентификаторов, используйте вместо этого 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)

Это проверит таблицу и вернется к следующему идентификатору.

Я попытался @anil shahsответить, и это сбросило личность. Но когда был вставлен новый ряд, он получил identity = 2. Поэтому вместо этого я изменил синтаксис:

DELETE FROM [TestTable]

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

Тогда первый ряд получит тождество = 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)

первый сбрасывает тождество на ноль, а следующий устанавливает его на следующее доступное значение - jacob

@jacob

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

Сработало для меня, мне просто нужно было сначала очистить все записи из таблицы, а затем добавить выше в триггерной точке после удаления. Теперь всякий раз, когда я удаляю запись, берется оттуда.

Truncate Таблица предпочтительна, потому что она очищает записи, сбрасывает счетчик и освобождает место на диске.

Deleteи CheckIdentдолжен использоваться только там, где внешние ключи не позволяют вам усекать.

Сброс идентификатора столбца с новым идентификатором ...

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

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

Это общий вопрос, и ответ всегда один и тот же: не делайте этого. Значения идентичности должны рассматриваться как произвольные, и, как таковой, нет «правильного» порядка.

Запустите этот скрипт, чтобы сбросить столбец идентификаторов. Вам нужно будет сделать два изменения. Замените tableXYZ на любую таблицу, которую нужно обновить. Кроме того, имя столбца идентификаторов необходимо удалить из временной таблицы. Это было мгновенно для таблицы с 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)

Это установит текущее значение идентичности в 0.

При вставке следующего значения значение идентификатора увеличивается до 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.

Второй производит 1, Item 1. Если вы выполните сброс сразу после того, как таблица создана, следующее значение равно 0. Честно говоря, я не удивлен, что Microsoft не может сделать это правильно. Я обнаружил это, потому что у меня есть файл сценария, который заполняет справочные таблицы, которые я иногда запускаю после повторного создания таблиц, а иногда, когда таблицы уже созданы.

Я использую следующий скрипт для этого. Есть только один сценарий, в котором он выдаст «ошибку», если вы удалили все строки из таблицы, и IDENT_CURRENTв настоящее время установлено значение 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)
;

Для полного удаления строк и сброса счетчика 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 не очень практично, если вы не чистите стол в целом.

В противном случае ответ Энтони Рэймонда идеален. Сначала получите максимальный столбец идентификаторов, затем начните с макс.

Я пытался сделать это для большого количества таблиц во время разработки, и это работает как очарование.

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

Итак, сначала вы устанавливаете значение 1, а затем устанавливаете на самый высокий индекс из строк, представленных в таблице. Быстрый и легкий отдых от idex.

Всегда лучше использовать TRUNCATE, когда это возможно, вместо удаления всех записей, поскольку он также не использует пространство журнала.

В случае, если нам нужно удалить и нам нужно сбросить начальное число, всегда помните, что если таблица никогда не заполнялась и вы использовали ее, DBCC CHECKIDENT('tablenem',RESEED,0) то первая запись получит identity = 0, как указано в документации по msdn.

В вашем случае только перестройте индекс и не беспокойтесь о потере серии идентификаторов, так как это распространенный сценарий.

Во-первых: просто укажите спецификацию: «Нет» >> Сохранить базу данных Выполнить проект

После этого: Идентификация идентификации просто: "ДА" >> Сохранить базу данных Выполнить проект

Ваш идентификатор базы данных, ПК Начните с 1 >>