Если у вас правильно описаны сущности, доктрина не тянет все сущности за раз, а только тогда, когда идёт обращение.
Чтобы "твиг" не делал миллион запросов к бд, пишут ручные запросы, без использования доктрины.
По коду, я могу предположить, что вы можете делать 2440 встакок кода, вместо одной большой.
А если у вас это вставляется всё же одним запросом, то возможно стоит разбить это допустим пачками по 100-200 строк.
В общем не понятно как у вас реализовано.
public function setCreate($entityMS)
{
$this->entityManager->persist($entityMS);
$this->entityManager->flush();
}
public function setSave()
{
$this->entityManager->flush();
}когда идёт обращение
2. То что редактируем или добавляем, через доктрину.
https://github.com/ElisDN/demo-project-manager/blo...
что показывает symfony debug?
там же если память не изменяет в последних версиях симфони можно посмотреть и статистику выполнение запросов.- про это тоже не скажу. Эти операции вставки-обновления делает команда, заданная в консоли. Как отследить тоже не знаю( я обернула строчки в тайминг, чтобы вычислить, сколько что работает)
$productBD = $this->getOne($id);
$flagCreate = false;
if ($productBD == null) {
$productBD = new Modeling();
$productBD->setId($id);
$flagCreate = true;
}
$productBD->setProduct($product->getProduct());
$productBD->setDateModeling($dateObj);
....
if ($flagCreate)
$this->setCreate($productBD);
else
$this->setSave();$this->createQueryBuilder("m")
->update()
->set('m.product',':product')
->set('m.dateModeling',':dateModeling')
....
->where("m.id=:id")
->setParameter('product',$productsEntity->getGuid())
->setParameter('dateModeling',$dateObj->format("Y-m-d"))
....
->setParameter('id', $id)
->getQuery()
->execute();"долгая вставка индекса первичного ключа" - это как бы сказки. Или, если на самом деле тормозит - то весьма вряд ли по вине MySQL, там же посредников не счесть.
Сортировка и группировка выполняется не по таблицам, а по выражениям. Но это к слову.
"сортируемые и группируемые поля добавить в самый конец индекса" ?? Какого индекса-то? не говоря уж о том, что индексов по выражениям, включающим поля нескольких таблиц - не существует. Не только в MySQL - вообще в любой СУБД.
Естественно это настройки сервера, в частности выделение памяти под временные таблицы, чтобы их тип был инмемори, а не диск. Нужен баланс между доступной памятью и выделенной под оптимизацию запросов в памяти. Кэш запросов, индексов, временные таблицы - все это желательно поместить в память.
Составной индекс если будут использоваться много полей, и отдельные если каждое из полей будет одиночной сортировкой.
Например на сайте новостей 1 секунда это много, а на приложении с миллиардами записей статистики по мировым продажам жвачки в розницу для планирования расширения сети продаж с 30 объединениями/группировками/дистинкт выборками надцать секунд или даже минут это норм, так как задача другая совершенно.
а explain подскажет где можно подкрутить что-то на уровне индексов/памяти, код при этом вообще не трогается. Да и по большому счету 99% типовых задач не пишутся руками, а пускаются через модель/орм.
Если вам нужен именно конкретный запрос с конкретным набором выходных данных, менять вы его не будете, логично что крутить вы можете только структуры данных и индексы, ну может еще что-то в настройках самого сервера.
Cпасибо,а почемку тогда
в одну строчку ,
не работает, а так работает.... Поэтомув я так и сделала ранее(см мой вопрос)