SQL Server 隔离级别真实世界示例答案

【问题标题】：SQL Server Isolation level real world exampleSQL Server 隔离级别真实世界示例
【发布时间】：2015-10-02 01:13:04
【问题描述】：

假设我们需要开发一个投标应用程序，例如 eBay 中的一个。我们不希望一个用户的出价阻止另一个用户的出价，这将导致响应缓慢。另外，当我根据我看到的最高价格出价时，我不想让应用程序说对不起，最高价格不再一样了；在我出价时，有人推高了价格。

我们应该使用哪种隔离级别？我在想Read Uncommitted 对于脏读和没有锁定但不确定。

我想听到更多关于 SQL Server 中隔离级别的真实示例/用例（或者一般来说，任何其他数据库软件，如果它们之间在隔离级别方面存在相似之处）。对我来说，我发现只看定义不是很有效。

谢谢。

【问题讨论】：

你的解释有点自相矛盾。首先，您说您不希望有人能够在有人出价时超过另一个人，但然后您说您愿意。我在 ebay 上遇到过这样的情况，我出价只是为了发现我不再是最高出价者。考虑一下如果您允许两个同时出价并且它们都是相同的价格，您的情况会发生什么。谁赢了？

标签： sql-server locking isolation-level read-uncommitted

【解决方案1】：

READ UNCOMMITTED 听起来不错，在您设想的场景中……但那个场景听起来很糟糕！

当我根据我看到的最高价格出价时，我不想让应用程序说对不起，最高价格不再一样了；在我出价时，有人推高了价格。

也许我误会了，但您的意思是在您准备出价时是否有其他人出价？如果是这样，它还有什么用处？即使您的出价较低，您会赢吗，仅仅因为您的出价开始的时间较早？那是行不通的。这必须在您的出价提交时决定。

真的，这应该与READ COMMITTED 一起运行，这样用户的出价就会受到之前所有出价的影响——在它提交的那一刻。这是合理拍卖的要求。投标应按时间顺序运行，由TRANSACTIONs 包裹，并且始终以交易开始时的最新最大值为准，即当用户点击提交按钮时，他们应以提交的所有投标的总和为准在他们之前。

【讨论】：

这个问题在我参加测试时出现过，所以我就记得写了，当他们描述场景时，我记得最好的两点：当前响应时间很慢并且发生阻塞+当我到达最后时，出价更高的问题。一个相关的想法：超时（例如 eBay 中的超时）如何适应这种竞价图景？例如，出价仍然取决于谁先开始，但超时避免让他霸占他人。这听起来像一个合理的场景吗？
我不是专家。但我认为我们需要区分开始投标的用户与用户提交投标后运行数据库事务的系统。前者可能需要一段时间（如果用户优柔寡断），不应该导致任何锁定，并且不应该阻止其他用户提交更高的出价，如果他们更快的话。后者应该相对快得多，应该包装在事务中以禁止脏读（例如当前最高出价的不一致视图）并确保顺序；这也可以确保按顺序处理出价，这很好。