Truy vấn Entity Framework chậm, nhưng SQL tương tự trong SqlQuery thì nhanh

Tôi thấy một số hiệu suất thực sự kỳ lạ liên quan đến một truy vấn rất đơn giản bằng cách sử dụng Entity Framework Code-First với .NET framework phiên bản 4. Truy vấn LINQ2Entities trông giống như sau:

 context.MyTables.Where(m => m.SomeStringProp == stringVar);

Quá trình này mất hơn 3000 mili giây để thực thi. SQL được tạo trông rất đơn giản:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = '1234567890'

Truy vấn này chạy gần như ngay lập tức khi chạy qua Management Studio. Khi tôi thay đổi mã C # để sử dụng hàm SqlQuery, nó sẽ chạy trong 5-10 mili giây:

 context.MyTables.SqlQuery("SELECT [Extent1].[ID] ... WHERE [Extent1].[SomeStringProp] = @param", stringVar);

Vì vậy, cùng một SQL chính xác, các thực thể kết quả được theo dõi thay đổi trong cả hai trường hợp, nhưng có sự khác biệt hoàn toàn giữa hai trường hợp. Đưa cái gì?

Tìm thấy rồi. Hóa ra đó là vấn đề về kiểu dữ liệu SQL. Các SomeStringPropcột trong cơ sở dữ liệu là một varchar, nhưng EF giả định rằng NET loại chuỗi là nvarchars. Quá trình dịch kết quả trong quá trình truy vấn để DB thực hiện so sánh là một việc mất nhiều thời gian. Tôi nghĩ rằng Giáo sư EF đã dẫn tôi đi lạc một chút ở đây, phần trình bày chính xác hơn về truy vấn đang được chạy sẽ như sau:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = N'1234567890'

Vì vậy, bản sửa lỗi kết quả là chú thích mô hình đầu tiên mã, chỉ ra kiểu dữ liệu SQL chính xác:

public class MyTable
{
    ...

    [Column(TypeName="varchar")]
    public string SomeStringProp { get; set; }

    ...
}

Lý do làm chậm các truy vấn của tôi được thực hiện trong EF là so sánh các đại lượng vô hướng không null với vô hướng vô hướng:

long? userId = 10; // nullable scalar

db.Table<Document>().Where(x => x.User.Id == userId).ToList() // or userId.Value
                                ^^^^^^^^^    ^^^^^^
                                Type: long   Type: long?

Truy vấn đó mất 35 giây. Nhưng một cấu trúc lại nhỏ như vậy:

long? userId = 10;
long userIdValue = userId.Value; // I've done that only for the presentation pursposes

db.Table<Document>().Where(x => x.User.Id == userIdValue).ToList()
                                ^^^^^^^^^    ^^^^^^^^^^^
                                Type: long   Type: long

cho kết quả đáng kinh ngạc. Nó chỉ mất 50ms để hoàn thành. Có thể đó là một lỗi trong EF.

Nếu bạn đang sử dụng ánh xạ thông thạo, bạn có thể sử dụng IsUnicode(false)như một phần của cấu hình để có được hiệu quả tương tự -

http://msdn.microsoft.com/en-us/data/jj591617.aspx#1.9

http://msdn.microsoft.com/en-us/library/gg696416%28v=vs.103%29.aspx

Tôi đã gặp vấn đề tương tự (truy vấn nhanh khi được thực thi từ trình quản lý SQL) nhưng khi thực thi từ EF thì hết thời gian chờ.

Hóa ra thực thể (được tạo từ chế độ xem) có khóa thực thể sai. Vì vậy, thực thể có các hàng trùng lặp với các khóa giống nhau và tôi đoán nó phải thực hiện nhóm trên nền.

Tôi cũng đã gặp điều này với một truy vấn ef phức tạp. Một bản sửa lỗi cho tôi đã giảm truy vấn ef 6 giây xuống truy vấn sql thứ hai mà nó tạo ra là tắt tải chậm.

Để tìm cài đặt này (ef 6), hãy truy cập tệp .edmx và tìm trong Thuộc tính -> Tạo mã -> Đã bật tải chậm. Đặt thành false.

Cải thiện đáng kể hiệu suất cho tôi.

Tôi cũng có vấn đề này. Hóa ra thủ phạm trong trường hợp của tôi là đánh hơi tham số SQL-Server .

Manh mối đầu tiên mà vấn đề của tôi trên thực tế là do đánh hơi tham số là chạy truy vấn với "set arithabort off" hoặc "set arithabort on" mang lại thời gian thực thi khác nhau đáng kể trong Management Studio. Điều này là do ADO.NET theo mặc định sử dụng "set arithabort off" và Management Studio mặc định là "set arithabort on". Bộ đệm ẩn kế hoạch truy vấn giữ các kế hoạch khác nhau tùy thuộc vào tham số này.

Tôi đã tắt bộ nhớ đệm kế hoạch truy vấn cho truy vấn, với giải pháp bạn có thể tìm thấy tại đây .