标签：date 成功 mes 为什么 不能 guid 应该 重复 upd
如何处理大量数据并发操作
文件缓存，数据库缓存，优化sql,数据分流,数据库表的横向和纵向划分，优化代码结构！
锁述的概
一. 为什么要引入锁
多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:
丢失更新
A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统
脏读
A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致
不可重复读
A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数据时发现前后两次的值不一致
并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致
我在博客堂上也看到不少有关并发控制的文章，我一直是推荐使用时间戳来解决的。
比如我们在SQL Server中的表中定义一个字段为timestamp类型的字段ts,这个字段的值不需要我们进行控制的。
在Insert与Update时，数据库会自己进行ts值的更新，因此我们只要在Update时使用：
Update xxx where key=@key and ts=@ts 就可以了，根本不用考虑ts里的值更新。
Delete时也最好进行一下判断，用这种方式是可以控制数据并发操作的。
只需要在Update与Delete时，判断"影响条数"就可以知道更新是否成功。
这一点我想非常方便，但不是所有的数据库都支持timestampr的，如在Access里没有timestamp字段，我也不知道其他的数据库是否都有类似的timestamp类型，不管怎么样，我觉得我们不能完全信赖于数据库的控制，而应该采用自设的控制机制，这样可以适应系统的数据库移值，下面我就介绍一下，在.NET下如何实现，自设的时间戳控制。
我们也同样建一个字段ts，定义为Varchar，长度在20以上即可，而且不允许为null，这样比较合适。
我们应该采用什么机制来生成随时的或者说不可能会产生一样的值，我推荐的是DateTime.Now.Ticks，这是一个12位的数字，由于在Update等更新时，数据库会自动进行锁定，所以不可能会在同一时间会有两个一样的操作执行，因此这就可以避免Ticks产生相同的值了。
或者也可以采用Guid值，也可以产生唯一值，但我觉得Guid值太大，可能会影响效率。
那好，在我们Insert时:Insert xxxx ts=‘221283747584‘ where key=‘1‘
在Update时 Update xx set xxx ts=‘39383848593839‘ where key=‘1‘ and ts=‘111111111111‘ //假设取到的原值为‘11111111111‘
Delete类似上面的。
我们判断影响条数，如果为0则说明更新不成功。
我相信上面的方法是简单可行的。
标签：date 成功 mes 为什么 不能 guid 应该 重复 upd
原文地址：http://www.cnblogs.com/ZkbFighting/p/7590628.html
