Я вижу, что это соединение (по умолчанию внутреннее соединение) и оно возвращает все столбцы, но это занимает почти то же время, что и ключевое слово для всего 1000 данных.
$ user-> join (‘profiles’, ‘users.id’, ‘=’, ‘profiles.user_id’) - генерирует следующий запрос.
select * from `users` inner join `profiles` on `users`.`id` = `profiles`.`user_id` where `first_name` LIKE '%a%'`
User :: with (‘profile’) - эта активная загрузка выводит следующий запрос
select * from `users` where exists (select * from `profiles` where `users`.`id` = `profiles`.`user_id` and `first_name` LIKE '%a%')
какой лучший способ вернуть список пользователей с разбивкой на страницы для REST API? нетерпеливая загрузка кажется многообещающей, но с подзапросом.
если делать с нетерпеливой загрузкой, я буду фильтровать именно так. нужно использовать где
if ($request->filled('first_name')){
$query->whereHas('profile',function($q) use ($request){
$q->where('first_name','like','%'.request('first_name').'%');
});
}
но если используется Join, меньше строк кода.
if ($request->filled('first_name')) {
$users = $users->where('first_name', 'LIKE', "%$request->first_name%");
}
версия laravel - 5.7
Убедитесь, что profiles.user_id является первой частью индекса или первичного ключа.






Eloquent - это реализация паттерна Active Record в Laravel, имеющая все свои сильные и слабые стороны. Это хорошее решение для использования, когда вы обрабатываете отдельный объект в режиме CRUD, то есть читаете из базы данных или создаете новый объект, а затем сохраняете его или удаляете. Вы получите много преимуществ от таких функций Eloquent, как грязная проверка (для отправки SQL UPDATE только для полей, которые были изменены), событий модели (например, для отправки административного предупреждения или обновления счетчика статистики, когда кто-то создал новую учетную запись), черты ( временные метки, мягкое удаление, пользовательские свойства) нетерпеливая / ленивая загрузка и т. д.
Но, как вы уже знаете, у него есть некоторая цена производительности. Когда вы обрабатываете одну или несколько записей, беспокоиться не о чем. Но для случаев, когда вы читаете много записей (например, для таблиц данных, для отчетов, для пакетной обработки и т. д.), Лучше подходит обычная БД.
Для нашего приложения мы делаем именно это - используя Laravel Eloquent в веб-формах для обработки одной записи и используя БД (с представлениями SQL) для извлечения данных для сеток, экспорта и т. д.
Когда дело доходит до производительности и роста приложения, для сравнения возьмите добычу в следующих таблицах:
Сравнение среднего времени отклика операции выбора между Eloquent ORM и Raw SQL
Красноречивое среднее время ответа ORM
Joins | Average (ms)
1 | 162,2
3 | 1002,7
4 | 1540,0
Результат выбора операции среднее время отклика для Eloquent ORM
Среднее время ответа на необработанный SQL
Joins | Average (ms)
1 | 116,4
3 | 130,6
4 | 155,2
Результат выбора операции среднее время отклика для Raw SQL
Привет, Dev1234, обычно я использую то, что быстрее, и обычно сводится к тому, сколько мне нужно для манипулирования данными с помощью PHP. Ни один из способов не является неправильным, но лучше использовать самый быстрый и эффективный способ, поскольку, как только вы получите много данных, обработка может занять много времени.