现象：
当业务涉及主从订单表时，主表主键OrderID为自增列，这时在涉及添加操作时，往往会出现如下的编程思路
insert order(...) values(...)
select @@identity
程序中再接收返回的值，作为OrderDetail表中OrderID的值，做Insert操作
问题：
单用户没有问题，小并发量可能没有问题
大并发量时，就会发现一个订单的明细，出现在另一个订单的明细中
这个问题我遇到过，新同事们也遇到过，因此，感觉是一个普遍的问题，其实问题很简单，问题涉及的知识点就是SCOPE_IDENTITY、IDENT_CURRENT 和 @@IDENTITY的区别
[引用Lich King]
IDENT_CURRENT 返回为任何会话和任何作用域中的特定表最后生成的标识值。
@@IDENTITY 返回为当前会话的所有作用域中的任何表最后生成的标识值。
SCOPE_IDENTITY 返回为当前会话和当前作用域中的任何表最后生成的标识值。
例如，有两个表 T1 和 T2，在 T1 上定义了一个 INSERT 触发器。当将某行插入 T1 时，触发器被激发，并在 T2 中插入一行。此例说明了两个作用域：一个是在 T1 上的插入，另一个是作为触发器的结果在 T2 上的插入。
假设 T1 和 T2 都有 IDENTITY 列，@@IDENTITY 和 SCOPE_IDENTITY 将在 T1 上的 INSERT 语句的最后返回不同的值。
@@IDENTITY 返回插入到当前会话中任何作用域内的最后一个 IDENTITY 列值，该值是插入 T2 中的值。
SCOPE_IDENTITY() 返回插入 T1 中的 IDENTITY 值，该值是发生在相同作用域中的最后一个 INSERT。如果在作用域中发生插入语句到标识列之前唤醒调用 SCOPE_IDENTITY() 函数，则该函数将返回 NULL 值。
而IDENT_CURRENT('T1') 和 IDENT_CURRENT('T2') 返回的值分别是这两个表最后自增的值。
因此，对于@@IDENTITY要尽量避免使用，因为在大型开发中，你根本无法知道你获得的是哪个自增列值，而尽量采用 SCOPE_IDENTITY() 函数，SCOPE_IDENTITY() 是在一个操作范围之内，最后一步操作所产生的自增列的值。