รีเซ็ตเมล็ดข้อมูลเฉพาะตัวหลังจากลบระเบียนใน SQL Server

ฉันได้แทรกบันทึกลงในตารางฐานข้อมูล SQL Server ตารางมีคีย์หลักที่กำหนดไว้และเมล็ดข้อมูลเฉพาะตัวของการเพิ่มอัตโนมัติถูกตั้งค่าเป็น "ใช่" สิ่งนี้เกิดขึ้นได้เนื่องจากใน SQL Azure แต่ละตารางจะต้องมีคีย์หลักและข้อมูลระบุตัวตน

แต่เนื่องจากฉันต้องลบบางระเบียนจากตารางเมล็ดข้อมูลประจำตัวสำหรับตารางเหล่านั้นจะถูกรบกวนและคอลัมน์ดัชนี (ซึ่งสร้างขึ้นโดยอัตโนมัติโดยเพิ่มขึ้น 1) จะถูกรบกวน

ฉันจะรีเซ็ตคอลัมน์ข้อมูลประจำตัวหลังจากที่ฉันลบระเบียนเพื่อให้คอลัมน์มีลำดับในการเรียงลำดับตัวเลขจากน้อยไปมาก

คอลัมน์ข้อมูลประจำตัวไม่ได้ใช้เป็น foreign key ในฐานข้อมูล

DBCC CHECKIDENTคำสั่งการจัดการจะใช้ในการตั้งค่าตัวตนที่เคาน์เตอร์ ไวยากรณ์คำสั่งคือ:

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

ตัวอย่าง:

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

ไม่รองรับในฐานข้อมูล Azure SQL เวอร์ชันก่อนหน้า แต่ได้รับการสนับสนุนแล้ว

โปรดทราบว่า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 มีข้อดีดังต่อไปนี้:

• ใช้พื้นที่บันทึกธุรกรรมน้อย

  คำสั่ง DELETE ลบแถวทีละรายการและบันทึกรายการในบันทึกธุรกรรมสำหรับแต่ละแถวที่ถูกลบ TRUNCATE TABLE ลบข้อมูลโดยการยกเลิกการจัดสรรหน้าข้อมูลที่ใช้ในการจัดเก็บข้อมูลตารางและบันทึกเฉพาะการยกเลิกการจัดสรรหน้าในบันทึกการทำธุรกรรม

• ล็อคที่น้อยลงมักจะใช้

  เมื่อคำสั่ง DELETE ดำเนินการโดยใช้การล็อคแถวแต่ละแถวในตารางจะถูกล็อคเพื่อลบ TRUNCATE TABLE จะล็อคตาราง (รวมถึงล็อค schema (SCH-M)) และหน้า แต่ไม่แต่ละแถว

• โดยไม่มีข้อยกเว้นหน้าศูนย์เหลืออยู่ในตาราง

  หลังจากดำเนินการคำสั่ง DELETE ตารางยังสามารถมีหน้าว่างได้ ตัวอย่างเช่นหน้าว่างในฮีปไม่สามารถยกเลิกการจัดสรรคืนได้หากไม่มีล็อคตารางแบบพิเศษ (LCK_M_X) เป็นพิเศษ หากการลบไม่ได้ใช้การล็อคตารางตาราง (ฮีป) จะมีหน้าว่างหลายหน้า สำหรับดัชนีการลบสามารถทิ้งหน้าเปล่าไว้ด้านหลังแม้ว่าหน้าเหล่านี้จะถูกจัดสรรคืนอย่างรวดเร็วโดยกระบวนการล้างพื้นหลัง

หากตารางมีคอลัมน์ข้อมูลเฉพาะตัวตัวนับสำหรับคอลัมน์นั้นจะถูกรีเซ็ตเป็นค่าเมล็ดที่กำหนดไว้สำหรับคอลัมน์ หากไม่มีการกำหนดเมล็ดพันธุ์จะใช้ค่าเริ่มต้น 1 หากต้องการเก็บตัวนับข้อมูลประจำตัวให้ใช้ DELETE แทน

ดังนั้นต่อไปนี้:

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

กลายเป็นเพียงแค่:

TRUNCATE TABLE [MyTable];

โปรดดูTRUNCATE TABLEเอกสารประกอบ (ลิงค์ด้านบน) สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อ จำกัด ฯลฯ

แม้ว่าคำตอบส่วนใหญ่จะแนะนำให้ RESEED เป็น 0 แต่หลายครั้งเราจำเป็นต้องส่งรหัสประจำตัวถัดไปให้พร้อม

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ตอบแล้วมันรีเซ็ตตัวตน identity = 2แต่เมื่อแถวใหม่ถูกแทรกมันได้ ดังนั้นฉันเปลี่ยนไวยากรณ์เป็น:

DELETE FROM [TestTable]

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

จากนั้นแถวแรกจะได้รับ identity = 1

ถึงแม้ว่าคำตอบส่วนใหญ่จะบอกRESEEDไป0และในขณะที่บางคนเห็นว่านี่เป็นข้อบกพร่องสำหรับTRUNCATEDตารางไมโครซอฟท์มีทางออกที่ไม่คิด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)
;

สำหรับแถว 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 จะไม่สามารถใช้งานได้จริงนอกเสียจากว่าคุณจะทำความสะอาดโต๊ะโดยรวม

ฉลาดคำตอบที่ได้รับจากแอนโธนีเรย์มอนด์ก็สมบูรณ์แบบ รับคอลัมน์ข้อมูลประจำตัวสูงสุดก่อนจากนั้นจึงสร้างด้วยจำนวนสูงสุด

ฉันพยายามทำสิ่งนี้ให้สำเร็จสำหรับตารางจำนวนมากในระหว่างการพัฒนาและมันก็ใช้งานได้ดี

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

ดังนั้นก่อนอื่นคุณต้องบังคับให้มันถูกตั้งค่าเป็น 1 จากนั้นคุณตั้งเป็นดัชนีสูงสุดของแถวที่มีอยู่ในตาราง ส่วนที่เหลืออย่างรวดเร็วและง่ายดายของ idex

มันจะดีกว่าเสมอในการใช้ TRUNCATEเมื่อเป็นไปได้แทนที่จะลบระเบียนทั้งหมดเนื่องจากไม่ได้ใช้พื้นที่บันทึก

ในกรณีที่เราต้องการลบและจำเป็นต้องรีเซ็ตเมล็ดโปรดจำไว้เสมอว่าถ้าตารางไม่เคยมีการเติมข้อมูลและคุณใช้DBCC CHECKIDENT('tablenem',RESEED,0) แล้วบันทึกแรกจะได้รับเอกลักษณ์ = 0 ตามที่ระบุไว้ใน เอกสาร MSDN

ในกรณีของคุณเพียงสร้างดัชนีใหม่และไม่ต้องกังวลกับการสูญเสียชุดข้อมูลประจำตัวเนื่องจากนี่เป็นสถานการณ์ทั่วไป

ครั้งแรก: ข้อมูลจำเพาะเกี่ยวกับผู้ใช้เพียง: "ไม่" >> บันทึกโครงการดำเนินการฐานข้อมูล

หลังจากนั้น: ข้อมูลจำเพาะของผู้ใช้เพียง: "ใช่" >> บันทึกโครงการดำเนินการฐานข้อมูล

ID ฐานข้อมูลของคุณ, PK เริ่มจาก 1 >>