IDENT_CURRENT 返回的是指定表在当前数据库中最后一次成功插入的标识值，它不绑定会话或作用域，可能被其他会话插入干扰，仅适用于有 IDENTITY 列的表，跨库查询需用三段式名称且权限足够。
IDENT_CURRENT 返回的是谁的值？
IDENT_CURRENT 返回的是指定表在当前数据库中**最后一次成功插入的标识值**，不管这个插入是由谁、在哪个会话、哪个事务里执行的。它不绑定当前会话（@@IDENTITY）也不绑定当前作用域（SCOPE_IDENTITY()），所以它可能返回你完全没预料到的值——比如另一个应用刚插入的一条记录。
常见错误现象：IDENT_CURRENT('Orders') 返回了 1024，但你自己刚 INSERT 的那条明明是第 5 条；原因很可能是后台任务或另一台服务正在高频写入 Orders 表。
- 只适用于有
IDENTITY列的表，对序列（SEQUENCE）无效 - 参数必须是字符串字面量或变量，不能是表达式，例如
IDENT_CURRENT(@table_name)合法，但IDENT_CURRENT('Order' + '_2024')会报错 - 如果表不存在、无
IDENTITY列，或调用者无查看权限，函数返回NULL，不会报错——这点容易被忽略，务必加IS NULL检查
为什么不能用 IDENT_CURRENT 替代 SCOPE_IDENTITY？
当你刚执行完 INSERT INTO Users (name) VALUES ('Alice')，紧接着想拿到新用户的 id，绝对不要用 IDENT_CURRENT('Users')。它可能被并发插入“污染”：同事的测试脚本、定时同步任务、甚至触发器里的隐式插入，都可能导致你取到别人的 ID。
正确做法永远是：SELECT SCOPE_IDENTITY()（T-SQL）或 OUTPUT INSERTED.id（更安全，支持多行）。
-
SCOPE_IDENTITY()只返回当前作用域最后生成的值，不受其他会话干扰 -
@@IDENTITY会被触发器里的INSERT带偏，而SCOPE_IDENTITY()不会 -
IDENT_CURRENT唯一适合的场景是：你明确需要“这张表历史上最近一次被谁插过”，比如审计、监控或故障排查
跨数据库查 IDENT_CURRENT 怎么写？
IDENT_CURRENT 默认只查当前数据库。要查其他库的表，得把三段式名称（database.schema.table）整个传进去，且数据库名必须是字符串常量——不能拼接变量，否则语法错误。
例如查 ArchiveDB 里 dbo.Logs 的最新标识值：
SELECT IDENT_CURRENT('ArchiveDB.dbo.Logs');
注意：ArchiveDB 必须存在，且当前登录用户对该库有 VIEW DEFINITION 权限（否则返回 NULL）。
- 不能写成
IDENT_CURRENT('ArchiveDB..Logs')（缺少 schema，可能失败） - 不能用双引号或方括号包裹表名，如
IDENT_CURRENT('[ArchiveDB].[dbo].[Logs]')会报语法错误 - 如果目标库处于单用户模式或离线状态，函数直接返回
NULL
IDENT_CURRENT 和 DBCC CHECKIDENT 的区别
IDENT_CURRENT 是只读查询，不修改任何状态；而 DBCC CHECKIDENT 是管理命令，能重置种子值，也能报告当前标识值（带 NORESEED 选项时行为接近 IDENT_CURRENT，但更重、更慢）。
别为了“查个值”去跑 DBCC CHECKIDENT('Orders', NORESEED)——它会获取表级架构锁，阻塞其他 DML，尤其在大表上代价明显。
- 查最新值，无条件选
IDENT_CURRENT('Orders') - 修复标识列跳号或越界问题，才用
DBCC CHECKIDENT('Orders', RESEED, 1000) -
DBCC CHECKIDENT的输出结果集结构不稳定（不同 SQL Server 版本字段名可能变），不适合程序解析
