Выбор первых 100 использований записей Linq
Все упомянули componentsSeparatedByString:, но можно также использовать CFStringTokenizer (помните, что NSString и CFString являются взаимозаменяемыми), который будет маркировать естественные языки также (как китаец/Японский язык, который не разделяет слова на пробелах).
5 ответов
Нет, это не возвращает все значения до фильтрации. Take (100) в конечном итоге станет частью отправляемого SQL - вполне возможно, с использованием TOP.
Конечно, имеет смысл сделать это, если вы указали orderby Предложение .
LINQ не выполняет запрос, когда он достигает конца выражения запроса. Он отправляет любой SQL только тогда, когда вы вызываете оператор агрегации (например, Count или Any ), либо когда вы начинаете перебирать результаты. Даже вызов Take на самом деле не выполняет запрос - например, вы можете добавить к нему дополнительную фильтрацию, которая в конечном итоге может стать частью запроса.
Когда вы начинаете итерацию по запросу результаты (обычно с foreach ) - , что '
Вы сравнивали стандартный запрос SQL с запросом linq? Какой из них быстрее и насколько значительна разница?
Я согласен с приведенными выше комментариями, что ваш запрос linq в целом правильный, но ...
- в вашем предложении 'where', вероятно, должно быть x == 1, а не x = 1 (сравнение вместо присваивания)
- 'select e' вернет все столбцы, где вам, вероятно, понадобятся только некоторые из них - точнее с предложением select (введите только необходимые столбцы); 'select *' - это огромное количество ресурсов
- убедитесь, что ваша база данных хорошо проиндексирована, и попробуйте использовать индексированные данные
В любом случае, база данных из 40 миллионов записей довольно огромна - вам нужны все эти данные все время? Может быть, какое-то разделение сократит его до наиболее часто используемых записей.
Я не думаю, что вы правы насчет того, что он возвращает все записи перед тем, как попасть в первую сотню. Я думаю, Linq решает, какой будет строка SQL во время выполнения запроса (также известного как Lazy Loading), и ваш сервер базы данных оптимизирует его.
Я согласен с Джоном Скитом, но просто хотел добавить:
Сгенерированный SQL будет использовать TOP для реализации Take ().
Если вы имея возможность запускать SQL-Profiler и пошагово выполнять свой код в режиме отладки, вы сможете точно увидеть, какой SQL создается и когда он выполняется. Если у вас найдется время для этого, вы многое узнаете о том, что происходит под ним.
Также есть свойство DataContext.Log, которому вы можете назначить TextWriter для просмотра сгенерированного SQL, например:
dbContext. Log = Console.Out;
Другой вариант - поэкспериментировать с LINQPad . LINQPad позволяет подключаться к источнику данных и легко пробовать различные выражения LINQ. На панели результатов вы можете переключиться, чтобы увидеть, как SQL сгенерировал выражение LINQ.
Я собираюсь рискнуть и предположить, что у вас нет индекса для столбца, используемого в вашем предложении where. Если это так, то он, несомненно, выполняет сканирование таблицы, когда запрос материализуется, и поэтому это занимает так много времени.