При маленьком количестве запросов можно и константы. Проблемы начинаются при большой нагрузке. Получилось что один не самый эффективный метод "из коробки" поменяли на другой не самый эффективный метод. При этом основной причиной называется универсальность такого подхода для "all modern" баз данных.
Так что сейчас подправят универсальность, а затем может и до IN с параметрами дело дойдет. Но выглядет так, что если все таки сделают, то выбирать его придется вручную. Как сейчас IN с константами или OPENJSON. А может это будет уже не Contains().
Пожалуйста! Но надо учитывать, что это "сырой" вариант. В нем нет бакетирования (bucketing, padding) переменных. А для MS SQL будет еще ограничение на 2100 параметров в запросе. Так как фильтр по двум ИД сразу, то максимальное количество фильтров 1050. Это если в этом же запросе не будет еще других условий, которые транслируются в параметры
Не научился, добавили больше способов отключить OPENJSON. Заняты с их точки зрения более приоритетными задачами. Хотя странно, что для своего же продукта оптимизацию не сделали.
При небольшом отношении (количество ИД) / (всего записей) быстрее работает IN с параметрами. По мере увеличения этого соотношения OPENJSON выравнивается с ним по скорости, а затем бывает даже чуть быстрее.
В идеале нужен гибридный подход, использующий заполнение параметров при небольших значениях, а OPENJSON для большого количества параметров. Но разработчики EFCORE считают, что архитектура запросов и кэширования EF делает это нетривиальной задачей.
Как только все текущие баги исправят, так обязательно запилят)
При маленьком количестве запросов можно и константы. Проблемы начинаются при большой нагрузке. Получилось что один не самый эффективный метод "из коробки" поменяли на другой не самый эффективный метод. При этом основной причиной называется универсальность такого подхода для "all modern" баз данных.
Так что сейчас подправят универсальность, а затем может и до
IN с параметрами
дело дойдет. Но выглядет так, что если все таки сделают, то выбирать его придется вручную. Как сейчасIN с константами
илиOPENJSON
. А может это будет уже неContains()
.Пожалуйста! Но надо учитывать, что это "сырой" вариант. В нем нет бакетирования (bucketing, padding) переменных. А для MS SQL будет еще ограничение на 2100 параметров в запросе. Так как фильтр по двум ИД сразу, то максимальное количество фильтров 1050. Это если в этом же запросе не будет еще других условий, которые транслируются в параметры
Не научился, добавили больше способов отключить
OPENJSON
. Заняты с их точки зрения более приоритетными задачами. Хотя странно, что для своего же продукта оптимизацию не сделали.При небольшом отношении
(количество ИД) / (всего записей)
быстрее работаетIN с параметрами
. По мере увеличения этого соотношенияOPENJSON
выравнивается с ним по скорости, а затем бывает даже чуть быстрее.В идеале нужен гибридный подход, использующий заполнение параметров при небольших значениях, а
OPENJSON
для большого количества параметров. Но разработчики EFCORE считают, что архитектура запросов и кэширования EF делает это нетривиальной задачей.Как только все текущие баги исправят, так обязательно запилят)
то можно взять такой вариант
FilterByItems()
:FilterByItems()
отсюда, с небольшими изменениями https://stackoverflow.com/questions/67666649/lambda-linq-with-contains-criteria-for-multiple-keywords/67666993#67666993Если надо так: