تعریف و جایگاه موضوع

IDENT_SEED مقدار Seed اولیه تعریف‌شده برای ستون Identity را برمی‌گرداند، درحالی‌که IDENT_CURRENT آخرین مقدار Identity تولیدشده برای جدول مشخص را بدون محدودیت Session و Scope گزارش می‌کند. این دو تابع کاربرد و ریسک کاملاً متفاوتی دارند.

این قابلیت را باید در کنار مفاهیم IDENT_CURRENT، IDENT_SEED، IDENTITY و SCOPE_IDENTITY تحلیل کرد. تصمیم درست تنها با مشاهده یک Query سریع حاصل نمی‌شود؛ بلکه نرخ رشد داده، الگوی DML، نحوه بارگذاری، محدودیت منابع و زمان نگه‌داری نیز باید وارد مدل تصمیم شوند.

چرا این موضوع مهم است؟

در جداول تحلیلی بزرگ، تفاوت میان طراحی درست و اجرای صرف یک دستور می‌تواند به اختلاف قابل‌توجه در IO، CPU و زمان پاسخ منجر شود. IDENT_CURRENT در برابر IDENT_SEED وقتی ارزش واقعی ایجاد می‌کند که با هدف کسب‌وکار، الگوی Query و ظرفیت زیرساخت هماهنگ باشد.

• بررسی پیکربندی Identity
• پایش مقدار جاری
• عیب‌یابی Reseed
• گزارش Metadata
• مقایسه با SCOPE_IDENTITY

به همین دلیل لازم است معیار موفقیت پیش از پیاده‌سازی تعریف شود. برای نمونه می‌توان زمان گزارش ماهانه، تعداد Rowgroupهای کم‌حجم، درصد ردیف‌های حذف‌شده، حجم Log یا تعداد Segmentهای خوانده‌شده را به‌عنوان شاخص پایه ثبت کرد.

نحو، اجزا و پارامترهای اصلی

نحو پایه زیر نقطه شروع است. نام شیء، Schema، پارتیشن و گزینه‌ها باید با محیط واقعی جایگزین شوند. در رشته‌های فارسی SQL از پیشوند N استفاده شده تا داده یونیکد درست ذخیره شود.

SELECT IDENT_SEED('dbo.Orders') AS SeedValue, IDENT_CURRENT('dbo.Orders') AS CurrentValue;

اجزای کلیدی

نوع خروجی بسته به موضوع ممکن است یک ساختار ایندکس، Plan اجرایی، مجموعه Rowgroup، شمارنده DMV یا مقدار عددی باشد. همیشه خروجی را با Metadata و Plan واقعی تأیید کنید؛ پیام موفقیت دستور به‌تنهایی نشان‌دهنده بهبود نیست.

فرایند تصمیم‌گیری و پیاده‌سازی

1. Workload اصلی را مشخص کنید و Queryهای پرتکرار مرتبط با IDENT_CURRENT در برابر IDENT_SEED را از Query Store یا مانیتورینگ استخراج کنید.
2. وضعیت فعلی IDENT_SEED و IDENTITY را ثبت کنید تا خط پایه قابل مقایسه باشد.
3. Syntax را در محیط آزمایشی اجرا کنید و اثر آن را روی هم‌زمانی و تبدیل نوع بسنجید.
4. سناریوهای بارگذاری، حذف، به‌روزرسانی، گزارش‌گیری و بازیابی خطا را جداگانه آزمایش کنید.
5. پس از تأیید، اجرای Production را با پنجره تغییر، Rollback Plan و گزارش کنترلی انجام دهید.

این روش مرحله‌ای مانع آن می‌شود که یک بهبود محلی، هزینه پنهان در ETL یا عملیات تراکنشی ایجاد کند. همچنین مستندسازی خروجی‌های قبل و بعد، تصمیم‌های نگه‌داری آینده را قابل دفاع می‌سازد.

۱۰ مثال عملی از ساده تا حرفه‌ای

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS SeedValue,
        IDENT_INCR(N'dbo.IdentityDemo') AS IncrementValue,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentValue;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'مشتری اول');

    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS SeedValue,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentValue;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    OUTPUT inserted.OrderID, inserted.CustomerName
    VALUES (N'سفارش هم‌زمان امن');

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    BEGIN TRANSACTION;
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'مشتری تراکنشی');

    SELECT
        SCOPE_IDENTITY() AS ScopeIdentityValue,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS TableCurrentValue;
    ROLLBACK;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS SeedValue,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentBeforeAnyInsert;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'الف'),(N'ب'),(N'پ');

    SELECT
        MIN(OrderID) AS MinID,
        MAX(OrderID) AS MaxID,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentValue
    FROM dbo.IdentityDemo;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'قبل از حذف');

    DELETE FROM dbo.IdentityDemo;

    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS SeedAfterDelete,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentAfterDelete;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'قبل از Truncate');

    TRUNCATE TABLE dbo.IdentityDemo;

    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS SeedAfterTruncate,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentAfterTruncate;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    VALUES (N'قبل از Reseed');

    DBCC CHECKIDENT (N'dbo.IdentityDemo', RESEED, 2000);

    SELECT
        IDENT_SEED(N'dbo.IdentityDemo') AS OriginalSeed,
        IDENT_CURRENT(N'dbo.IdentityDemo') AS CurrentAfterReseed;

USE tempdb;
    DROP TABLE IF EXISTS dbo.IdentityDemo;
    CREATE TABLE dbo.IdentityDemo
    (
        OrderID bigint IDENTITY(1000,5) NOT NULL PRIMARY KEY,
        CustomerName nvarchar(100) NOT NULL
    );
    INSERT INTO dbo.IdentityDemo(CustomerName)
    OUTPUT inserted.OrderID
    VALUES (N'روش پیشنهادی');

    -- این روش برای دریافت شناسه همان درج از IDENT_CURRENT امن‌تر است.
    SELECT IDENT_CURRENT(N'dbo.IdentityDemo') AS MonitoringOnly;

خطاهای رایج

خطاهای زیر در پروژه‌های واقعی مرتبط با Ident_Current VS Ident_Seed In SQL Server دیده می‌شوند. شدت هر خطا به حجم داده و نسخه SQL Server وابسته است، اما اصل کنترل برای همه محیط‌ها یکسان است.

• استفاده IDENT_CURRENT برای شناسه درج فعلی
• نادیده گرفتن Session دیگر
• فرض یکی بودن Seed و Current
• Race Condition
• استفاده بدون Schema

ملاحظات کارایی و پایش

برای ارزیابی IDENT_CURRENT در برابر IDENT_SEED حداقل پنج محور باید هم‌زمان دیده شود: هم‌زمانی, تبدیل نوع, Truncate/Empty Table, Reseed, امنیت Metadata. اندازه‌گیری تنها زمان اجرا ممکن است نتیجه گمراه‌کننده بدهد، زیرا Cache گرم، Parallelism، Memory Grant و بار هم‌زمان روی نتیجه اثر دارند.

یک Snapshot منفرد برای تصمیم بلندمدت کافی نیست. داده پایش را در چند بازه کاری، پس از ETL و در ساعات اوج جمع‌آوری کنید تا روند واقعی مشخص شود.

بهترین روش‌ها

• برای Insert از OUTPUT استفاده کنید
• نام Schema را کامل بنویسید
• IDENT_SEED را Metadata بدانید
• IDENT_CURRENT را برای کنترل هم‌زمانی استفاده نکنید
• DBCC CHECKIDENT را با احتیاط اجرا کنید

Best Practice به‌معنای اجرای یک نسخه ثابت برای همه سرورها نیست. باید توصیه‌ها را با اندازه داده، Edition، Compatibility Level، معماری HA/DR و محدودیت پنجره نگه‌داری تطبیق داد.

پرسش‌های متداول

IDENT_CURRENT در برابر IDENT_SEED دقیقاً چه مشکلی را حل می‌کند؟

IDENT_SEED مقدار Seed اولیه تعریف‌شده برای ستون Identity را برمی‌گرداند، درحالی‌که IDENT_CURRENT آخرین مقدار Identity تولیدشده برای جدول مشخص را بدون محدودیت Session و Scope گزارش می‌کند. این دو تابع کاربرد و ریسک کاملاً متفاوتی دارند. انتخاب آن باید براساس نوع بارکاری و معیارهای قابل اندازه‌گیری انجام شود.

برای شروع یادگیری Ident_Current VS Ident_Seed In SQL Server چه پیش‌نیازی لازم است؟

آشنایی با Execution Plan، ایندکس‌ها و دستورات پایه T-SQL کافی است. سپس باید مفاهیم IDENT_SEED و IDENTITY را روی یک پایگاه داده آزمایشی مشاهده کنید.

آیا IDENT_CURRENT در برابر IDENT_SEED برای همه پروژه‌های تجاری مناسب است؟

خیر. سودمندی آن به حجم داده، نسبت خواندن به نوشتن، SLA گزارش‌ها و هزینه نگه‌داری وابسته است. ارزیابی فنی یا مشاوره SQL Server پیش از استقرار می‌تواند از هزینه‌های بازطراحی جلوگیری کند.

هزینه پیاده‌سازی IDENT_CURRENT در برابر IDENT_SEED چگونه برآورد می‌شود؟

برآورد باید شامل تحلیل Workload، طراحی آزمایش، زمان مهاجرت، پایش پس از اجرا و آموزش تیم باشد. اندازه جدول و حساسیت توقف سرویس نیز روی زمان انجام پروژه اثر مستقیم دارد.

تفاوت IDENT_CURRENT در برابر IDENT_SEED با یک ایندکس یا روش عمومی چیست؟

روش عمومی معمولاً فقط ساختار یا دستور را می‌بیند، اما این موضوع روی IDENT_CURRENT، SCOPE_IDENTITY و رفتار واقعی موتور تمرکز دارد. مقایسه باید با Plan، IO، CPU و مدت اجرا انجام شود.

چه زمانی برای اجرای پروژه یا دریافت خدمات مرتبط با Ident_Current VS Ident_Seed In SQL Server مناسب است؟

هنگامی که گزارش‌ها کند شده‌اند، رشد داده سریع است یا نگه‌داری فعلی نتیجه قابل پیش‌بینی ندارد، بررسی تخصصی ارزشمند است. بهتر است ابتدا Snapshot فنی و معیار موفقیت تعیین شود.

رایج‌ترین خطا در استفاده از IDENT_CURRENT در برابر IDENT_SEED چیست؟

یکی از خطاهای پرتکرار «استفاده IDENT_CURRENT برای شناسه درج فعلی» است. خطای دیگر تصمیم‌گیری بدون مقایسه قبل و بعد و بدون توجه به نسخه SQL Server است.

IDENT_CURRENT در برابر IDENT_SEED چه اثری بر Performance دارد؟

اثر اصلی از مسیر هم‌زمانی، تبدیل نوع و Truncate/Empty Table دیده می‌شود. نتیجه می‌تواند بسیار مثبت یا در Workload نامناسب منفی باشد، بنابراین تست کنترل‌شده ضروری است.

بهترین روش عملی برای IDENT_CURRENT در برابر IDENT_SEED چیست؟

از یک محیط آزمایشی مشابه Production شروع کنید، برای Insert از OUTPUT استفاده کنید و نام Schema را کامل بنویسید را اجرا کنید و معیارها را در Query Store یا سامانه پایش ثبت نمایید.

سازگاری Ident_Current VS Ident_Seed In SQL Server با نسخه‌های SQL Server چگونه است؟

این رفتار در نسخه‌های فعلی SQL Server پایدار است؛ برای دریافت شناسه درج‌شده در همان Scope معمولاً SCOPE_IDENTITY یا OUTPUT انتخاب امن‌تری است. پیش از انتشار در Production، Syntax و گزینه‌های قابل پشتیبانی را روی همان Edition، Version و Compatibility Level بررسی کنید.

سؤالات مصاحبه

پاسخ مناسب به پرسش‌های زیر باید علاوه بر تعریف، شامل سناریو، Trade-off، معیار اندازه‌گیری و نمونه T-SQL باشد.

1. تفاوت IDENT_CURRENT و IDENT_SEED را با یک سناریوی واقعی توضیح دهید.
2. برای سنجش اثر Ident_Current VS Ident_Seed In SQL Server چه شاخص‌هایی را قبل و بعد ثبت می‌کنید؟
3. در چه شرایطی «استفاده IDENT_CURRENT برای شناسه درج فعلی» باعث افت کارایی می‌شود؟
4. چگونه با استفاده از IDENTITY و SCOPE_IDENTITY مشکل را عیب‌یابی می‌کنید؟
5. در طراحی یک Job سازمانی برای IDENT_CURRENT در برابر IDENT_SEED چه کنترل خطا و Rollback در نظر می‌گیرید؟
6. چرا توصیه «برای Insert از OUTPUT استفاده کنید» برای محیط Production مهم است؟

چک‌لیست نهایی

1. نسخه و Compatibility Level برای Ident_Current VS Ident_Seed In SQL Server کنترل شد.
2. خط پایه IO، CPU، Duration و فضای مصرفی ثبت شد.
3. Query و Syntax در محیط آزمایشی اجرا شد.
4. اثرات DML و ETL جداگانه سنجیده شد.
5. خروجی DMV یا Metadata پس از اجرا بررسی شد.
6. Rollback Plan و ظرفیت Log مشخص شد.
7. گزارش مقایسه قبل و بعد ذخیره شد.
8. Job یا رویه نگه‌داری دارای شرط و کنترل خطا است.