Linq Query需要很長時間

Question

以下是長期的 -

using (var db = new Agreements_DBEntities())
{

    bool isProfileExist = (from ua in db.UserAgreementDetails
                                     where ua.uID == uID &&
                                           ua.uMailId == uMailId &&
                                           ua.uType == uType &&
                                           ua.UProfile.HasValue && ua.UProfile.Value
                                     select true).Any();
}

以上行bool isProfileExist花了太長時間......它有什么問題？

Answer 1

好吧，我想你可以刪除where子句並直接使用Any （我不確定IQueryable提供程序將如何優化Linq）以及你如何對它進行基准測試但是：

db.UserAgreementDetails.Any(ua => ua.uID == uID &&
                                           ua.uMailId == uMailId &&
                                           ua.uType == uType &&
                                           ua.UProfile.HasValue && ua.UProfile.Value);

即使這樣，你在db中有多少行？ 這是第一次執行查詢等。？

Answer 2

首先要做的是檢查生成的實際查詢。 SQLServer Profiler非常適合這種情況，其他數據庫也有其他查詢日志記錄方法。

如果我們將查詢的不必要位簡化為：可能會產生更好的SQL：

bool isProfileExist = db.UserAgreementDetails.Any(
    ua => ua.uID == uID &&
    ua.uMailId == uMailId &&
    ua.uType == uType &&
    ua.UProfile.HasValue &&
    ua.UProfile.Value);

我想這會產生幾乎相同的代碼，但它可能不會，如果查詢提供程序給出了一些奇怪的東西，那值得嘗試。

在那之后，我猜（但不能確定）主要罪魁禍首實際上是數據庫服務器。 檢查是否有一個索引或索引集使這個查詢快速執行。

想法索引可能是覆蓋與uID ， uMailId ， uType和UProfile相對應的列，或包含其中一些和“擁有”其他列的列。 但是，人們不需要單獨考慮這個查詢，因此您可能會決定對它們使用單​​獨的索引，或者只是覆蓋某些索引的索引：特別是，如果只有少量行具有相同的uID ，那么一個正好應該做的工作的索引，不需要增加插入成本，也可以使更多的其他查詢受益。