Jak mogę prześledzić zapytanie SQL wygenerowane przez EF z powrotem do kodu, który je utworzył

Question

Mam problem z wolnymi uruchomieniami zapytań, które widzimy tylko w produkcji, i widzę słabo działający SQL w profilerze, jednak Nie wiem, jak mogę tego użyć, aby prześledzić z powrotem do kodu, który wygenerował oświadczenie w pierwszej kolejności, lub jeśli śledzenie z powrotem do kwerendy EF jest możliwe. Czy EF ma jakąkolwiek możliwość zidentyfikowania pochodzenia instrukcji SQL, aby pomóc w odnalezieniu problemu w kodzie?

wierzę, to problem może być związany z załadunkiem kod załadunku pesymistycznie, czyli jego załadunku ustawić całe wyniki, a następnie filtrowanie listy w kodzie zamiast filtrując go w SQL

Answer 1

można wykonać następujące czynności, w twoim repozytorium lub DataContext (wspólne miejsce wykonywania zapytań) do debugowania zapisu każdego zapytania.

var data= from item in entity 
       where item.id = 564564 
       select item;  
Debug.WriteLine(((System.Data.Objects.ObjectQuery)data).ToTraceString()); 

Możesz napisać następujący kod, aby powiedzieć, jaki jest stos wywoławczy po wykonaniu powyższego zapytania. Następnie znajdź zapytanie, którego szukasz, a stos wywołań powie Ci, gdzie zostało wykonane zapytanie.

StackTrace stackTrace = new StackTrace();   // get call stack 
StackFrame[] stackFrames = stackTrace.GetFrames(); 

Możesz użyć śledzenia microsoft lub log4net, aby zarejestrować te rzeczy, a następnie łatwo znaleźć zapytanie.

Answer 2

Można utworzyć inną jednostkę w bazie danych (np. DebugEntity) i uruchomić zapytanie na niej tuż przed/po faktycznych zapytaniach.

ctx.DebugEntity.Where(x => x.ID == "myId1"); //myId2, myId3, myId4, whatever helps you locate the LINQ query from the profiler... 

Powinno to pojawić się w programie profilującym SQL.