Принудително параметризиране на Entity Framework Order By

Използвам нещо подобно на DynamicLinq, за да позволя резултатите от Entity Framework да бъдат подредени по низ, който съответства на име на свойство. Изглежда обаче, че всеки път, когато свойството за сортиране се промени, кешираният SQL не се използва, а вместо това се генерира нов израз. Това, което търся, е начин да накарам Entity Framework да използва SQL параметър за клаузата ORDER BY в SQL изразите, които генерира.

Успях да преодолея подобен проблем с методите .Skip() и .Take(). Така че съответните SELECT TOP N и WHERE ROW_NUMBER > M са правилно параметризирани в SQL изхода.

Има ли някакъв начин да накарате SQL изхода да използва клауза ORDER BY, която е нещо като:

ORDER BY [Foo].[@p__linq__24]

От гледна точка на SQL това трябва да е възможно.


.net entity-framework entity-framework-6
person user653649    schedule 05.06.2014    source източник
comment
поправете ме, ако греша, но, както го казахте, използването на параметър там не е разрешено.   -  person hometoast    schedule 05.06.2014
comment
свързано, но не съвсем дубликат: stackoverflow.com/questions/2378728/order-by-a-parameter   -  person hometoast    schedule 05.06.2014
comment
Как успяхте да го направите с Skip и Take?   -  person Ben Aaronson    schedule 05.06.2014
comment
@BenAaronson погледнете тук: stackoverflow.com/questions/9201403/   -  person user653649    schedule 05.06.2014
comment
@hometoast ТРЯБВА ДА е възможно да го направите в SQL с sp_executesql и динамичен SQL оператор, което е точно как работи Entity Framework.   -  person user653649    schedule 05.06.2014
comment
благодаря @user653649, не бях обмислял sp_executesql   -  person hometoast    schedule 05.06.2014

Отговори (1)


arrow_upward
0
arrow_downward

SQL Server не приема параметри за ORDER BY.

Но освен тази подробност, по-важното е следното: когато дадена заявка ще бъде изпълнена, SQL сървърът създава оптималния план за изпълнение на заявката. Когато прави това, той решава кои индекси да използва, как се филтрират редовете, как се комбинират таблиците и т.н. И промяната на реда на резултата не е толкова тривиална, че да се очаква, че предишният план за изпълнение е все още валиден (например може да реши да използва различен индекс).

С други думи, планът за изпълнение се използва повторно само ако промените в заявката са тривиални (като промяна на стойността на филтър). И дори така, в зависимост от статистиката и селективността на филтриращата стойност, той може да реши да го направи по различен начин. Например представете си битова колона, която има 999 реда със стойност 0 и 1 колона със стойност 1. Ако статистиката е правилно актуализирана, SQL сървърът знае, че филтрирането по стойност 1 е оптимално в този индекс (изключително селективно) и филтрирането по 0 е безсмислено (почти неселективно).

Освен ако не се сблъсквате с екстремни случаи, в които наистина трябва да оптимизирате, не се притеснявайте за това.

Можете да направите свои собствени тестове, като проверите „Показване на плана за изпълнение на заявката“ в SSMS и разгледате плана за изпълнение (истинския, а не очаквания... Не знам точната формулировка на английски, имам локализиран SSMS ).

person JotaBe    schedule 06.06.2014
comment
Не се опитвам да оптимизирам SQL плана, а по-скоро принуждавам Entity Framework да използва същия SQL оператор за заявка, независимо от реда по свойство. Entity Framework използва параметризирани динамични SQL изрази за изпълнение на своите заявки. Това означава, че елементите в клаузите where са параметри, предадени в sql израз. Тези отчети са кеширани. По този начин не е необходимо да компилира цялото дърво на израза в sql всеки път. За сложни заявки това е огромен ускорител на производителността. Търся начин да параметризирам клаузата за ред по същия начин като клаузата where. - person user653649; 06.06.2014
comment
Дори ако това, което искате да направите, е от страна на EF, подреждането по не може да бъде параметризирано. Измерихте ли повишаването на производителността или просто си въобразявате? Не трябва да се притеснявате за производителността, освен ако не е ясно, че има сериозен проблем с производителността. Може да ви е интересно да прочетете тази обширна статия за EF оптимизации: msdn.microsoft.com/en -US/data/hh949853, специално 3.2.2 - person JotaBe; 06.06.2014