由于我的表记录存在非常持久的锁定问题......
在我的带有 SQL-Server 数据库的 ASP.Net MVC Web 应用程序中对 Entity Framework 6 的所有选择查询使用“未提交”事务隔离级别是否正确？
我应该考虑哪些危险、限制和考虑因素？
问问题
56 次
1 回答
0
典型的“脏读”潜在问题可以通过查询“看到”尚未提交到数据库的更改，包括事务回滚的幽灵记录。这可能意味着行在完全提交之前返回到搜索结果中。如果 EF 系统是写入数据库的数据的“看门人”，这可能不是什么大问题，因为幽灵只会在 SaveChanges 调用期间出现，但如果您使用事务范围等并保存范围内的变化，鬼/脏数据可能会在事务范围的持续时间内出现。
当涉及到诸如搜索和报告之类的繁重读取操作时，您可以选择针对为脏读设置的单独 DbContext 实例运行这些操作，但您应确保SaveChanges重写 DbContext 方法以引发异常以防止它被意外用于写。理想情况下，脏读的实体声明应该完全独立地声明，以区分根据锁定规则读取的实体与可能是脏的实体。（不可靠）当涉及到大型系统的报告时，我通常的目标是在单独的复制只读数据库实例上运行。
我建议首先考虑对所有大型只读操作（如搜索）利用投影，以便执行的查询仅返回必要的数据，以及避免低效查询所需的所有数据由于序列化等原因需要或触发延迟加载，再次提取不需要的数据。这有助于确保不需要触及的表不会被触及（有锁定问题的风险），还有助于确保查询尽可能快地运行，从而减少锁定问题的窗口长度。这通常足以使典型使用系统保持足够的响应速度，并且不会遇到搜索和读/写场景的锁定问题。它还有助于优化搜索以尽可能利用索引，并避免用户过度自由的查询可能导致表扫描等事情。（速度慢且容易出现跳闸问题）
于 2021-04-14T23:14:50.660 回答