问一个简单的问题 关于锁

Rawu

实现订货功能的程序 如果用户查询库存的时候使用共享锁 则会出现因为后台库存管理的操作的影响 而造成性能低下。而且如果因为异常问题，后台操作迟迟不能提交，则前台就会影响用户使用的意向；但如果用with ur ， 则会出现返回信息与实际信息不一致的情况。请教 如何处理这种情况呢 ？？谢谢

足球小子

这并不是什么简单的问题，需要根据业务需求认真考虑。

如果正在只读数据库上执行查询，或者正在执行查询而不考虑是否有未提交的数据值返回，则使用“未提交的读”隔离级别。（需要是只读事务 — 不需要较高的数据稳定性。）

如果希望在不看见未提交数据值的情况下获得最大的并发性，则使用“游标稳定性”隔离级别。（需要是读／写事务 — 不需要较高的数据稳定性。）

如果希望获得并发性，并希望限定的行在单个事务执行期间保持稳定，则使用“读稳定性”隔离级别。（需要是只读或读／写事务 — 需要较高的数据稳定性。）

如果正在执行查询，并且不希望看到对产生的结果数据集进行更改，则使用“可重复的读”隔离级别。（需要是只读事务 — 需要极高的数据稳定性。）


除非是针对只读的业务，否则不要轻易使用UR隔离级。如果感觉使用CS隔离级仍然导致系统的性能过低，可以考虑把应用程序中的事务设置得再短小一些（当然前提是保证业务的正常），原来用一个大事务实现的功能改为几个小事务。这样并发性会好一些。

Rawu

谢谢你的回复 ， 看来只有把事务缩短尽快提交来优化了。
但是， 如果一个业务处理上有很多步骤的话，在不可能中途提交的前提下，要优化也就只能优化业务流程了，是吗？

PS 如果是只读的事务，那么用不用UR ，有什么不同？