مقدمه

@@IDENTITY یکی از قابلیت‌های سیستمی Transact-SQL است که در عیب‌یابی، کنترل عملیات و ثبت Metadata کاربرد دارد. این مقاله از تعریف پایه شروع می‌کند و سپس با ده مثال مستقل، رفتار واقعی آن را در SQL Server توضیح می‌دهد.

آخرین مقدار Identity تولیدشده در کل نشست جاری را بدون محدودیت Scope برمی‌گرداند. دانستن همین تعریف کافی نیست؛ باید مرز نشست، Scope، آخرین Statement و اثر دستورهای بعدی را نیز شناخت تا مقدار خروجی به اشتباه به عملیات دیگری نسبت داده نشود.

در پروژه‌های عملی بهتر است استفاده از @@IDENTITY بخشی از یک قرارداد روشن باشد: دستور اجرا می‌شود، مقدار بلافاصله دریافت می‌گردد، وضعیت خطا یا تراکنش کنترل می‌شود و نتیجه لازم برای لاگ یا لایه برنامه بازگردانده می‌شود.

برای مشاهده جایگاه این قابلیت در کنار سایر توابع سیستمی، راهنمای جامع توابع سیستمی SQL Server را نیز مطالعه کنید.

تعریف، کاربرد و مرز عملکرد

نوع خروجی @@IDENTITY برابر numeric(38,0) است. هنگام ذخیره در ستون یا متغیر، نوع مقصد را آگاهانه انتخاب کنید؛ تبدیل ضمنی ممکن است در حجم بالا، مقدار بزرگ یا تغییر Schema باعث خطای سرریز یا رفتار پیش‌بینی‌نشده شود.

Trigger می‌تواند مقدار آن را تغییر دهد؛ برای دریافت شناسه همان Scope معمولاً SCOPE_IDENTITY انتخاب امن‌تری است. این نکته به‌ویژه زمانی مهم است که Trigger، Dynamic SQL، Stored Procedure تو‌در‌تو، Connection Pooling یا چند دستور تشخیصی در مسیر اجرا وجود دارد.

خروجی صفر، NULL یا مقدار قدیمی الزاماً خطای موتور نیست؛ گاهی تعریف تابع دقیقاً چنین رفتاری دارد. برای تحلیل درست، یک آزمایش کوچک در همان اتصال بسازید و قبل و بعد از هر Statement مقدارهای مرتبط را ثبت کنید.

قاعده طلایی: Trigger می‌تواند مقدار آن را تغییر دهد؛ برای دریافت شناسه همان Scope معمولاً SCOPE_IDENTITY انتخاب امن‌تری است. نتیجه را همراه با زمینه اجرا تفسیر کنید و از تبدیل یک مقدار سیستمی به فرض تجاری بدون آزمون پرهیز نمایید.

Syntax و نوع خروجی

نحو پایه @@IDENTITY کوتاه است، اما محل فراخوانی آن معنای خروجی را تعیین می‌کند. نمونه زیر خروجی را با نام ستونی واضح ارائه می‌دهد تا مصرف آن در ابزار گزارش‌گیری یا کد برنامه خوانا باشد.

SELECT @@IDENTITY AS LastIdentityInSession;

نوع بازگشتی numeric(38,0) است. برای API یا لایه داده، نوع C# یا مقصد پایگاه داده را مطابق همین نوع و دامنه مقادیر انتخاب کنید و حالت NULL را، هرجا از نظر معنایی ممکن است، صریح مدیریت نمایید.

مثال‌های عملی از پایه تا حرفه‌ای

ده مثال زیر مستقل طراحی شده‌اند. هر نمونه هدف، Query کامل، خروجی مورد انتظار و نکته کاربردی دارد. اشیای آزمایشی را در پایگاه توسعه اجرا کنید و از اجرای کدهای آموزشی روی Production بدون بازبینی مجوز و اثر قفل خودداری نمایید.

CREATE TABLE #Customer(Id int IDENTITY(1,1), Name nvarchar(40));
    INSERT #Customer(Name) VALUES(N'مینا');
    SELECT @@IDENTITY AS NewId;
    DROP TABLE #Customer;

CREATE TABLE #Item(Id int IDENTITY(10,1), Title nvarchar(20));
    INSERT #Item(Title) VALUES(N'A');
    INSERT #Item(Title) VALUES(N'B');
    SELECT @@IDENTITY AS LastId;
    DROP TABLE #Item;

CREATE TABLE #Batch(Id int IDENTITY(1,1), Code char(1));
    INSERT #Batch(Code) VALUES('A'),('B'),('C');
    SELECT @@IDENTITY AS LastGeneratedId;
    DROP TABLE #Batch;

CREATE TABLE #Invoice(Id bigint IDENTITY(1000,1), Amount money);
    INSERT #Invoice(Amount) VALUES(125000);
    SELECT CONVERT(bigint, @@IDENTITY) AS InvoiceId;
    DROP TABLE #Invoice;

-- در اتصال تازه ممکن است مقدار NULL باشد
    SELECT @@IDENTITY AS SessionIdentity;

CREATE TABLE #ScopeDemo(Id int IDENTITY, Value int);
    INSERT #ScopeDemo(Value) VALUES(7);
    SELECT @@IDENTITY AS SessionId, SCOPE_IDENTITY() AS ScopeId;
    DROP TABLE #ScopeDemo;

CREATE TABLE #OutputDemo(Id int IDENTITY, Name nvarchar(20));
    INSERT #OutputDemo(Name) OUTPUT inserted.Id VALUES(N'کالا');
    SELECT @@IDENTITY AS SessionLastId;
    DROP TABLE #OutputDemo;

CREATE TABLE #Ticket(Id int IDENTITY(500,5), Subject nvarchar(30));
    INSERT #Ticket(Subject) VALUES(N'پشتیبانی');
    DECLARE @TicketId numeric(38,0) = @@IDENTITY;
    SELECT @TicketId AS TicketId;
    DROP TABLE #Ticket;

CREATE TABLE #SafeId(Id int IDENTITY, Value int);
    INSERT #SafeId(Value) VALUES(9);
    SELECT CONVERT(int, SCOPE_IDENTITY()) AS RecommendedId,
           CONVERT(int, @@IDENTITY) AS SessionId;
    DROP TABLE #SafeId;

CREATE TABLE #BulkId(Id int IDENTITY, Code varchar(10));
    DECLARE @Ids TABLE(Id int);
    INSERT #BulkId(Code) OUTPUT inserted.Id INTO @Ids VALUES('X'),('Y');
    SELECT Id FROM @Ids ORDER BY Id;
    DROP TABLE #BulkId;

خطاهای رایج

بخش مهم یادگیری @@IDENTITY شناخت خطاهایی است که Syntax صحیح دارند اما منطق نادرست تولید می‌کنند. این خطاها ممکن است در تست تک‌کاربره دیده نشوند و فقط زیر بار یا با Trigger آشکار گردند.

• 1. فرض برابری همیشگی با SCOPE_IDENTITY. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 2. تبدیل مستقیم به int بدون توجه به نوع numeric. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 3. خواندن مقدار پیشین نشست پس از عملیاتی که Identity نساخته. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 4. استفاده برای جدول مشخص به‌جای IDENT_CURRENT. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.

در رخداد واقعی، تنها پیام خطا کافی نیست. نام Procedure، شماره خط، ورودی‌های پالایش‌شده، وضعیت تراکنش و شناسه نشست را ثبت کنید تا علت اصلی از نشانه ثانویه تفکیک شود.

Performance و بهینه‌سازی

خواندن آن سبک است، اما اتکا به مقدار مبهم در زنجیره Triggerها می‌تواند خطاهای داده‌ای پرهزینه ایجاد کند.

برای سنجش اثر واقعی، قبل و بعد از تغییر کد از Query Store، Actual Execution Plan، SET STATISTICS IO/TIME و در صورت نیاز Extended Events استفاده کنید. اندازه‌گیری باید روی Query اصلی، تعداد Logical Read، زمان CPU، مدت قفل و حجم Log متمرکز باشد.

از اجرای Query اضافی فقط برای بازسازی اطلاعاتی که موتور همان لحظه در اختیار گذاشته اجتناب کنید. در عین حال، تابع سیستمی را جایگزین کنترل صحت داده، Constraint، ایندکس مناسب یا طراحی Transaction نکنید.

در پردازش گروهی، نتیجه هر Batch را ثبت کنید و اندازه Batch را طوری تنظیم نمایید که زمان قفل و رشد Log قابل کنترل باشد. شکست جزئی باید سیاست Retry محدود و Idempotency مشخص داشته باشد.

بهترین روش‌ها و کاربرد سازمانی

• مقدار @@IDENTITY را در نزدیک‌ترین نقطه به دستور مرجع بخوانید.
• نوع خروجی numeric(38,0) و امکان NULL یا صفر را صریح در مدل داده لحاظ کنید.
• برای خطا از TRY...CATCH، THROW و XACT_STATE با قرارداد یکسان استفاده کنید.
• کد را زیر هم‌زمانی واقعی و در حضور Trigger یا Connection Pooling آزمایش کنید.
• از Hard-code کردن نام محیط و فرض‌های وابسته به ترتیب اجرا خودداری کنید.
• در لاگ، SPID، زمان، نام دیتابیس و شناسه همبستگی را بدون داده حساس نگه دارید.

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

برای مهاجرت نسخه یا انتقال به محیط جدید، مجموعه تست سازگاری بسازید. Compatibility Level، مجوز DMVها، رفتار Driver و تنظیمات Connection Pool می‌توانند روی مشاهده‌پذیری پیرامون تابع اثر بگذارند، حتی اگر Syntax خود تابع ثابت مانده باشد.

سؤالات متداول

پرسش 1: @@IDENTITY دقیقاً چه کاری انجام می‌دهد؟

@@IDENTITY آخرین مقدار Identity تولیدشده در کل نشست جاری را بدون محدودیت Scope برمی‌گرداند. خروجی باید در متن همان Batch و با توجه به Scope، Session و دستور قبلی تفسیر شود؛ جدا کردن آن از زمینه اجرا می‌تواند نتیجه‌ای ظاهراً درست اما از نظر تجاری اشتباه بسازد.

پرسش 2: بهترین زمان خواندن @@IDENTITY چه موقع است؟

بهترین زمان بلافاصله پس از دستور مرتبط است. اگر مقدار برای چند مرحله بعد لازم است، آن را در متغیری با نوع مناسب ذخیره کنید و همراه شناسه عملیات ثبت نمایید تا دستورهای واسط مقدار یا معنای آن را تغییر ندهند.

پرسش 3: آیا @@IDENTITY برای سامانه‌های سازمانی مناسب است؟

بله، مشروط بر اینکه قرارداد استفاده، مدیریت خطا و تست هم‌زمانی مشخص باشد. در طراحی حرفه‌ای، این تابع بخشی از راه‌حل است و در کنار Transaction، Logging، مجوز حداقلی و پایش Query به کار می‌رود.

پرسش 4: برای پیاده‌سازی صحیح آن به مشاوره SQL Server نیاز است؟

در کد ساده خیر، اما در سامانه‌های مالی، انبار، احراز هویت یا پردازش گروهی بررسی Triggerها، Scopeها و الگوی تراکنش اهمیت زیادی دارد. بازبینی تخصصی می‌تواند از خطاهای خاموش و هزینه اصلاح داده جلوگیری کند.

پرسش 5: تفاوت @@IDENTITY با گزینه‌های نزدیک چیست؟

تفاوت اصلی در دامنه مشاهده و نوع اطلاعات است. باید مشخص شود نیاز شما مربوط به آخرین Statement، نشست جاری، Scope جاری، جدول مشخص یا Metadata سرور است؛ سپس تابعی انتخاب شود که دقیقاً همان مرز را پوشش دهد.

پرسش 6: آیا می‌توان این الگو را در Stored Procedure پروژه پیاده کرد؟

بله. بهتر است مقدار در همان Procedure گرفته شود، نوع خروجی صریح باشد، خطا با TRY...CATCH مدیریت شود و نتیجه از طریق Result Set، پارامتر OUTPUT یا قرارداد سرویس بازگردد. تست یکپارچه نیز حالت موفق و شکست را پوشش دهد.

پرسش 7: خطای رایج هنگام استفاده از @@IDENTITY چیست؟

فرض برابری همیشگی با SCOPE_IDENTITY یکی از خطاهای متداول است. خطای دیگر، اتکا به نتیجه بدون ثبت Context اجراست. نسخه اصلاح‌شده باید زمان خواندن، Scope، رفتار تراکنش و نوع تبدیل را آشکار کند.

پرسش 8: اثر @@IDENTITY بر Performance چیست؟

خواندن آن سبک است، اما اتکا به مقدار مبهم در زنجیره Triggerها می‌تواند خطاهای داده‌ای پرهزینه ایجاد کند. هزینه اصلی معمولاً از Query یا Transaction پیرامون آن می‌آید، نه خود تابع. اندازه‌گیری با Actual Execution Plan، Query Store و Extended Events باید روی کل جریان انجام شود.

پرسش 9: Best Practice اصلی برای @@IDENTITY چیست؟

مقدار را نزدیک به دستور مرجع بخوانید، در نوع مناسب ذخیره کنید، نتیجه‌های مرزی مانند صفر یا NULL را تست کنید و برای عملیات حساس گزارش ممیزی بسازید. از تکیه بر ترتیب اتفاقی دستورات یا رشته‌های Hard-coded دوری کنید.

پرسش 10: این قابلیت در کدام نسخه‌های SQL Server کار می‌کند؟

این قابلیت در نسخه‌های رایج و پشتیبانی‌شده SQL Server در دسترس است، اما امکانات مکمل مانند SESSION_CONTEXT، THROW یا برخی DMVها به نسخه و سطح سازگاری وابسته‌اند. پیش از استقرار، مستندات همان نسخه و Compatibility Level پایگاه داده را کنترل کنید.

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

سؤال 1: مرز مشاهده @@IDENTITY چیست؟

پاسخ حرفه‌ای باید مشخص کند تابع به Statement، Scope، Session، Table یا Server مربوط است و یک مثال نقض نیز ارائه دهد. گفتن نام تابع بدون توضیح مرز مشاهده برای مصاحبه فنی کافی نیست.

سؤال 2: چگونه مقدار را بدون Race Condition مصرف می‌کنید؟

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

سؤال 3: در CATCH چه اطلاعاتی ثبت می‌کنید؟

شماره و متن خطا، Procedure، Line، XACT_STATE، @@TRANCOUNT، نام پایگاه داده، SPID و شناسه همبستگی از اطلاعات مفید هستند. داده حساس نباید بدون پالایش وارد Log شود.

سؤال 4: چطور این کد را تست می‌کنید؟

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

سؤال 5: چه زمانی گزینه دیگری را انتخاب می‌کنید؟

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

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

• تعریف و مرز @@IDENTITY را با یک مثال توضیح داده‌ام.
• مقدار بلافاصله پس از دستور مرتبط ذخیره می‌شود.
• حالت صفر، NULL، خطا و هم‌زمانی تست شده است.
• تراکنش در مسیر موفق Commit و در مسیر شکست Rollback می‌شود.
• نتیجه با نوع مناسب و نام ستون روشن به لایه مصرف‌کننده می‌رسد.
• لاگ فنی برای عیب‌یابی وجود دارد و داده حساس ثبت نمی‌شود.

جمع‌بندی

@@IDENTITY آخرین مقدار Identity تولیدشده در کل نشست جاری را بدون محدودیت Scope برمی‌گرداند. استفاده حرفه‌ای از آن به معنی شناخت دقیق مرز، خواندن در زمان مناسب، مدیریت نوع خروجی و آزمون رفتار در شرایط واقعی است.

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