2013-05-06 41 views
7

Tôi đang sử dụng Entity Framework 5, ObjectContext và POCO trên lớp truy cập dữ liệu của tôi. Tôi có một thực thi chung chung và tôi có một phương thức truy vấn cơ sở dữ liệu với phân trang bằng cách sử dụng Skip() và Take(). Tất cả mọi thứ hoạt động tốt, ngoại trừ việc thực hiện truy vấn là rất chậm khi bỏ qua rất nhiều hàng (Tôi đang nói về 170K hàng)Khuôn khổ thực thể Bỏ qua phương pháp chạy rất chậm

Đây là một đoạn trích của các truy vấn của tôi trên LINQ to Entities:

C# Mã :

ObjectContext oc = TheOBJEntitiesFactory.CreateOBJEntitiesContext(connection); 
var idPred = oc.CreateObjectSet<view_Trans>("view_Trans").AsQueryable(); 
idPred = idPred.OrderBy(sortColumn, sortDirection.ToLower().Equals("desc")); 
var result = idPred.Skip(iDisplayStart).Take(iDisplayLength); 
return new PagedResult<view_Trans>(result, totalRecords); 

trong truy vấn dịch sang Transact-SQL tôi nhận thấy rằng thay vì sử dụng ROW_NUMBER() khoản với quan điểm trực tiếp của nó làm cho một phụ truy vấn và áp dụng các ROW_NUMBER() các kết quả của tiểu truy vấn ...

dụ:

select top(10) extent1.A, extent1.B.extent1.C from (
select extent1.A, extent1.B, extent1.C, 
row_number() OVER (ORDER BY [Extent1].[A] DESC) AS [row_number] 
from (
select A,B,C from table as extent1)) as extent1 
WHERE [Extent1].[row_number] > 176610 
ORDER BY [Extent1].[A] DESC 

này mất khoảng 165 giây để hoàn thành. Bất kỳ ý tưởng về cách cải thiện hiệu suất của câu lệnh truy vấn đã dịch?

+2

Vì truy vấn nhanh mà không có sự bỏ qua, điều này cho thấy rằng vấn đề nằm trong SQL, chứ không phải là các lĩnh vực xem xét hiệu suất khác trong khung thực thể. Vì vậy, điều đầu tiên tôi sẽ làm là sử dụng SQL Profiler để chẩn đoán tại sao truy vấn chậm. Bạn đã thử cái này chưa? Bạn đã tìm thấy gì? –

+0

Tôi đã làm điều đó. Tôi nghĩ rằng vấn đề là trong subquery không cần thiết đang được xây dựng bởi Entity Framework, khi tôi thực hiện cùng một truy vấn bằng cách sử dụng LinqToSql thay vì Entity Framework, kết quả không giống nhau và truy vấn nhanh hơn rất nhiều (~ 30 giây). Nếu bạn thấy Sql trong ví dụ trên, có một truy vấn con không cần thiết đối với bảng và row_number không được áp dụng cho bảng, mà là kết quả của truy vấn con đó. – Boanerge

+0

Điều đó không thực sự trả lời câu hỏi của tôi. Truy vấn con bạn đổ lỗi xuất hiện trong rất nhiều truy vấn EF mà không cần 165s để hoàn thành. SQL Profiler sẽ cung cấp cho bạn thông tin cụ thể hơn. Cái gì, chính xác, đang gây ra 165s? –

Trả lời

0

Một lý do cho sự chậm chạp có thể là sql của bạn đang sắp xếp các hàng của bạn hai lần.

Để kiểm soát truy vấn, tùy chọn duy nhất tôi biết là gọi idPred.SqlQuery ("Chọn ...", thông số). Điều này sẽ cho phép bạn viết truy vấn được tối ưu hóa của riêng bạn cho yêu cầu dữ liệu.

+2

Nếu bạn định bỏ phiếu cho tôi, bạn có thể vui lòng bình luận để cho tôi biết có gì sai với câu trả lời của tôi không? –

1

Đối với những người không theo các ý kiến ​​ở trên, tôi nghi ngờ vấn đề không phải là thêm SELECT, vì thêm SELECT có mặt trên nhiều, nhiều truy vấn EF không dùng 165s để chạy. Cuối cùng tôi nhận thấy rằng ObjectSet của anh ta đã tham chiếu một VIEW và tự hỏi liệu đó có phải là một phần của vấn đề hay không. Sau một số thử nghiệm, ông đã thu hẹp sự cố xuống một số LEFT JOIN bên trong chế độ xem. Tôi đề nghị rằng anh ta chạy Database Tuning Advisor trên truy vấn đó; anh ta đã làm, và hai chỉ số đề xuất cố định vấn đề.