C# 开发中遇到的MSSQL 锁的问题
0
[已解决问题]
解决于 2016-08-08 12:51
假如有2 表 （用户表）USER和(日志表)LOGS 表,表字段我只列出需要用到的
用户表字段
ID int
name nvarchar(50)
umoney money
日志表
ID int
UID int 此字段为用户表ID
amoney money 变动后金额
bmoney money 变动前金额
cmoney money 变动金额
现在就是程序对用户的金额进行操作，操作的来源不唯一，可能是后台，可能是客户自己操作了什么东西，或者其他地方的来源
如何保证 用户表和日志表的 金额不出错，且不出现死锁
我现在的方案是使用事务来处理的，用户表的那条数据加锁，直到此事务处理完毕。这样就有一个问题了，就是容易出现死锁。。。本人对MSSQL锁了解得不是非常深入，使用上有问题
我的使用方式
开始事务
select * XXX with(xlock,rowlock)
。。。。。。。。。。一系列操作
提交事务
我一直觉得有什么不对的地方
求指教。。
最佳答案
0
这个就是信息社会中信息爆炸带来的恶果之一。（其实也不能怪信息社会，要怪也只能怪自己）
一个程序员甲，他的工作是给银行开发软件，月薪10万，
另外一个程序员乙，他的工作是给用户数不超过100个的企业开发软件，月薪5千。
程序员乙问程序员甲，这个数据库该如何设计，这个更新SQL该如何写，
如果双方都不清楚对方的背景的情况下，传授出来的经验十成有九成是错误的。
不知道楼主能不能看懂我想表达的意思。
奖励园豆：5
我说的不够清楚还是有什么问题，请说
@未来由我开启: 确实不够清楚，我的意思就是不同数量级的并发，使用的是不同的方法。
包括设计数据库的方式就不同。看楼主的数据库设计、表达、SQL语句，完全没有办法看出楼下所说的
“实际的应用场景”这几个字。
其实很容易的，有1000台电脑，估计5%并发查询，1%并发更新之类的，这样的描述你总会有吧。
就是说你的软件有多少台电脑在用？数据表有多少行记录？数据库有多大？这些简单的描述性不会涉及到隐私吧？
总不能你问我有6000元如何开个淘宝店，我说你先上CCAV做个广告吧。
@爱编程的大叔: 哦哦 是我考虑不周，不过 既然我提出了这个问题，根据这个问题的描述来看的话 肯定是在极端情况下出现的问题，即 出现死锁的这种情况，我问这个问题的目的就是要防止多线程同时在处理的时候出现死锁。访问量 你可以向极端方向考虑，目的就是避免死锁。
如果是我的表设计本来就有问题，方便的话你可以告诉我一个你认为可行的方案。
@未来由我开启: 其实我也想问一下王思聪，只有两只手，那么多妹子怎么顾得过来。会不会出现死锁...
听你话里的意思，差不多意思是中国银行请来帮忙开发系统这样子，这个我还真帮不上忙。
我得先研究下两只手的问题去。
@爱编程的大叔: 哦哦 还是谢谢了
其他回答(3)
0
不需要事务,你用一条语句,update的时候output into到日志表
谢谢，我找资料看看。。。这个真没用过。。。有问题再问你
果然OK了，，，简单方便
0
根据实际的应用场景设置事务的隔离级别比较好。
http://www.cnblogs.com/qanholas/archive/2012/01/02/2310164.html
正在看你所提供的文章，写得很好，虽然我还没看完，，，我对数据库研究不是很深入，看着某些地方有点迷糊。
0
1.事务一般只在本地数据库，而且闲时率很高的时段使用。
2.对数据库做update、insert、delete操作时，会开启表锁和行锁。如果执行事务做以上三种操作，当事务不提交时，表锁和行锁对表数据持续锁定状态，其他对话只能等到本事务完成（提交redo/undo日志，提交修改数据，解除表锁行锁，提示当前对话操作完成）后才能对表数据做操作。
你有什么比较好的思路吗 ，我能想到的就是 提高代码执行效率，简化一部分不必要的流程。。。
求指点。。。
@未来由我开启:
不使用事务；如果需要提交数据行很多，可以分批提交，比如每一批500行或1000行，根据提交数据量而定。
这样做的好处
1.减少调用次数；
2.每次调用传送的有效字节占比率会变大（可以去看下通讯协议，有写不必要的字节在一次通讯中是必不可少的，较少调用次数也相当于减少了传送这些不必要字节），提高调用效率；
3.如果这个功能使用很频繁，建议使用 存储过程（procedure , 同样也是为了提高传送的有效字节占比率）
@小尧弟:
说得有道理
批量提交 一般来说是针对 那种时时性要求不高的数据，像日志数据，公司项目就是这样处理的。
但是像我这样的日志，有变动前金额，变动金额，变动后金额，，，应该行不通
我平时对调用很平凡的SQL 都是使用存储过程来处理的
谢谢你的建议
@未来由我开启: 那就一条一条的提交吧。
不过如果是大型网站，或者并发调用率很高的服务， 建议 批量处理数据 和 建立数据缓冲池，并保留操作日志（非数据库层的）。
