是这样的，插入之前做过重复判断。第一次插入，Transaction还没完成。所以第二次插入前数据库中还没，这样就导致重复了。

@心亦: 还原一下你的场景，

1、多线程。

2、只要是多线程，不管是大数据，还是小数据，理论上都存在第一次插入没完成的情况下，

第二次检测已经发生。就是说不管你执行速度有多快，0.1NS也好，都存在并发考虑。

3、那么为啥会出现一线程和二线程有相同的业务数据，能不能在这个上面思考一下呢？

你是想解决问题呢，还是只想从一个方向解决问题？

@爱编程的大叔: 这个业务数据是用户提供，也没法控制。

最后的问句没读懂啊。想解决问题的

@心亦: 那么再问一句，瓶颈是数据库，还是CPU计算能力？

1、如果是数据库的话，可以考虑不要多线程。

2、业务数据用户提供？包括主键？（比如像我们使用的主键是无任何意义的GUID，与业务无关）

3、延时5分钟，排队（类似MSMQ)，只用一个线程（或者多线程也行），这样5分钟内的数据可以先

保证这部分数据是不重复的。（不会出现一线程没完成的业务，和二线程的检测无效的问题）

4、即便你的信息比较不方便透露，但是你可以将一些关键点说下的，

比如数据怎么来：每分钟过来500条数据，每天24小时不间断。

数据怎么组织? 比如说数据是 客户、日期、金额，单据号。单据号可能重复，重复的话使用第一条还是第二条，因为什么原因重复了，能不能在前一道工序上去重？

为啥主键是没法自行控制的？

为啥会出现同样的业务数据？

能不能插入前（我指不通过数据库检测直接去重复）排除？

数据处理的时效性要求?

@爱编程的大叔: 

1 数据库单线程的方法请指教一下。

2 是用户提供主键

3 引入队列好像会更加复杂

4 数据是wcf post来的，用户频繁操作两次导致了这个问题。要在代码去重，那肯定要将一定时间内的数据缓存起来，和3的方案相同吧。

@心亦: 好，那么问题可以不可以这样理解。

1、多线程，一线程、二线程。

2、插入数据，假设是一条就行，都存在并发冲突的问题，与事务无关。

3、数据库是可以限制主键重复的，也就是第二次插入直接就ERROR了。

4、那么这个逻辑哪一步是你不能接受的。

Insert into PrimaryID, Title values (1, "测试")   一线程

Insert into PrimaryID, Title values (1,"其他测试"）  二线程

这样第二次插入直接就出错了。

5、还是说，你那个所谓的业务主键，根本就不是数据库主键，数据库是允许重复的？

6、如果是第5条所说的情况，那么事后补救是否可行，就是另外运行一个线程，专门检查业务数据重复，发现重复删除。

@爱编程的大叔: 用户输入的业务主键并没有唯一约束，因为允许逻辑删除后再添加一条业务主键相同的数据

@爱编程的大叔: 谢谢，有没有在sql中单线程的方法？类似于c#的lock。C#代码中不能用是因为有负载均衡，多台server同时跑。

@心亦: 逻辑删除就是只做标识，不从数据库删除是吧。

那么延时处理，事后处理方式呢？

@心亦: 负载均衡，这个说到要点了。你必须告诉别人，什么是你不能承受的，或者是不可修改的。

1、多应用服务器-单数据库。

2、如果重复插入了，后期删除会造成什么问题？

3、数据库锁定你可以看这篇文章： 

SQL Server数据库表锁定原理以及如何解除表的锁定

可以锁定表的，但不知道你是否可以承受？

@爱编程的大叔: 是的。

这样也是一种方案。但这个发生频率不是很高，搞个线程一直跑不太好吧。

@爱编程的大叔: 谢谢。嗯，还是利用数据库的锁好些