Нужно сделать подгрузку через with у огромного кол-ва моделей, из-за

этого падаю с ошибкой General error: 1390 Prepared statement contains too many placeholder
Хочу переделать на join чтобы был один sql запрос а не whereIn с миллионами элементов в массиве. Но тогда все ломается, т.к. запрос сложный и везде нужно указывать префикс основной таблицы. Какие решения есть? Либо чтобы дать указание того чтобы не писать префикс в where а по дефолту использовать основную таблицу либо аналог with/join чтобы подгрузить большое количество связанных записей (аналог - есть 100к постов у каждого по 10 комментариев, надо подгрузить всё)

что то не так у тебя с выборкой, зачем тебе тянуть 1кк записей по relation, что-то не так выстроено в логике

а как определить проблему? Могу описать один из кейсов, есть импорт, в цикле поданного на вход элементу надо сопоставить элемент из базы, точнее связанный с ним (абстрактный пример - импорт постов, нужно проверить нет ли поста с определенным комментарием. Если уже есть, то взять его и актуализировать)

whereIn() на 1кк возникает, т.к. выборка выбирает 1кк записей, а нужно ли это, почему проверку на существование не проверить через sql запрос, а не как сейчас все выбрал а потому по циклу попытка найти соответствие если без этого не как, то как минимум отказаться от жадной загрузки

Если sql запрос на каждой итерации - можно, но получается N+1, а если заранее то мы не знаем какое значение искать, оно ведь в импорте. Пришла еще идея, сделать chunk по 10к записей и каждую такую Eloquent/Collection делать load('comments') подгружать нужное и складывать в общую коллекцию. Будет что-то вроде +- 200 запросов на 1млн записей. Это все в конструкторе

по твоим абстрактным примерам, у тебя посты и коменты должны быть как то свзяаны, сначала по запросу находишь коммент, потом по ид комметна ищешь посты, и по нима уже updateOrCreate

В цикле? Ну это самое простое, да. Но это очень накладно по запросам, нужно оптимизировать. Если импорт на 1млн то это габелла по времени к сожалению

не стольк накладно как 1кк записаей дергать, 5 мелкиих запросов в 1000 раз быстрее твоего на 1кк

что значит лучше? у тебя на вход летят данные, которые нужно добавить или обновить, в твоей концепции загрузить все придется для каждой строки загружаемых данных, выгружать все частями ... ерунда какая то получается и в итоге на 200 новых записей у тебя будет из базы вытянуто 200кк записей

оптимизация в перую очередь производится исключением ORM лары в запросах, на фасад ДБ сначала переносишь все тяжелые запросы, ток потом логику трогаешь

Нет, это же в конструкторе и только один раз

Делаю загрузку в конструкторе всех данных, потом в цикле просто по коллекции ищем нужное через связь

а за то что это все в конструторе железной ржавой линейкой по рукам, чтоб больше так не делал

Вероятно да, видимо проще обычным DB найти значение, его post_uuid и потом достать модель, не знаю, надо замеры делать что лучше

дело даже не столько в этом, сколько дернуть 1кк строк в виде массива из базы !== сбилдить 1кк объектов модели

Сравню эти два варианта