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