.net - linq 与 sql(或 .NET 应用程序与 SQL Server Management Studio)

Question

我有一个 linq 查询，它根据 id 列(其中 id=@id)从 View 中检索行

此查询需要 4 秒才能运行。我使用 SQL Server Profiler 来检查 linq 执行的查询，如果我将该查询直接复制到 Management Studio 并执行，则该查询只需要 56 毫秒。

这种指数时间增长在我的应用程序中对 View 的所有 linq 查询中是一致的。当相同的查询执行 < 100 毫秒时，是什么导致我的 (WPF) 应用程序执行时间延长？

==编辑==

我已经设法进一步隔离，评论显示分析器持续时间；

/* 3953ms, 111487 reads */
context.SkuView.Where(p => p.TermId == 35 && !p.IsDeleted).ToList(); 

/* 90ms, 173 reads */
context.SkuView.Where(p => p.TermId == 35).ToList(); 

如果我将(sql 渲染的)linq 查询直接粘贴到 ssms 中，我得到；

/* 250ms, 173 reads */
SELECT * FROM SkuView WHERE TermId == 35 AND IsDeleted = 0

/* 250ms, 173 reads */
SELECT * FROM SkuView WHERE TermId == 35

所以问题与使用 !p.IsDeleted 时通过 linq 的读取计数有关...

Answer 1

可能的罪魁祸首是:

• 争用。从 Linq 运行时，其他应用程序事件会锁定行，从而导致查询停止等待锁。从 SSMS 运行时，没有其他事件，因此查询很快完成。
• 参数类型的差异。传递 NVARCHAR 参数来与 VARCHAR 列进行比较会导致完全扫描(由于 Data Type Precedence 规则，无法使用索引)。这是由错误的 LINQ ColumnAttribute 引起的。从 SSMS 运行时，查询通常会被错误复制，并且参数类型会更改为 VARCHAR。
• 冷运行与热运行。查询首先由 LINq 运行，这会预热缓存(将数据从磁盘获取到内存)。当再次从 SSMS 运行时，无需等待 IO。

无论如何，调查工具都可供您使用。

• 比较两个查询的读取次数(Profiler 中的 RPC:Complete 、 TSQL:BatchComplete 事件)
• 比较计划。使用Showplan XML事件。
• 看看 LINq 查询在做什么:sys.dm_exec_requests wait_type、wait_time 和 wait_resource 列
• 比较两种情况的查询统计信息:sys.dm_exec_query_stats 。需要注意的是，逻辑读取和物理读取这两种情况之间存在巨大差异，表明计划截然不同(扫描与查找)，或者 elapsed_time 存在巨大差异，但工作时间相似(表明可能存在阻塞、锁定)。