Здравствуйте, gandjustas, Вы писали:

G>select * запрашивает метаданные, что заметно влияет на время. Но проблема не в этом, а в том, что ты тянешь поля, которые не используешь. Это повышает нагрузку на базу, сеть, приложение, и, самое главное, не позволяет построить покрывающий индекс.
Если нудно одно или пару полей понятно что не будешь использовать *, а вот если и нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять?

G>Предложу вариант логику формирования предикатов вынести в приложение. Ты же в приложении знаешь будет у тебя параметр null или нет.
G>Тогда в приложении пишешь:
G>

G>IQueryable<X> ApplyParamY(IQueryable<X> source, Y y)
G>{
G>    return y==null?source:source.Where(x => x.Y == y.Value);
G>}
G>

G>У тебя получаются разные запросы по разным комбинациям параметров и ты можешь построить разные индексы, которые разные ускоряют разные запросы.
Если я правильно понимаю, в таком случае каждый раз когда запрос отправляется на сервер будет строится план, верно? Все равно лучше чем уже имеющийся нестабильный?

G>Причем если у тебя таблица большая и очень разряженая, то можно использовать фильтрованные индексы, офигенно добавляют скорости.
G>Вот тут было — http://gandjustas.blogspot.com/2014/09/asp.net-linq-ef-sql-server-performance.html
Спасибо, почитаю.

Здравствуйте, gandjustas, Вы писали:

G>select * запрашивает метаданные, что заметно влияет на время. Но проблема не в этом, а в том, что ты тянешь поля, которые не используешь. Это повышает нагрузку на базу, сеть, приложение, и, самое главное, не позволяет построить покрывающий индекс.
Если нужно одно или пару полей понятно что не будешь использовать *, а вот если нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять?

G>Предложу вариант логику формирования предикатов вынести в приложение. Ты же в приложении знаешь будет у тебя параметр null или нет.
G>Тогда в приложении пишешь:
G>

G>IQueryable<X> ApplyParamY(IQueryable<X> source, Y y)
G>{
G>    return y==null?source:source.Where(x => x.Y == y.Value);
G>}
G>

G>У тебя получаются разные запросы по разным комбинациям параметров и ты можешь построить разные индексы, которые разные ускоряют разные запросы.
Если я правильно понимаю, в таком случае каждый раз когда запрос отправляется на сервер будет строится план, верно? Все равно лучше чем уже имеющийся нестабильный?

G>Причем если у тебя таблица большая и очень разряженая, то можно использовать фильтрованные индексы, офигенно добавляют скорости.
G>Вот тут было — http://gandjustas.blogspot.com/2014/09/asp.net-linq-ef-sql-server-performance.html
Спасибо, почитаю.