это лучше вторым multi join UPDATE'ом сделать сделать и индексы правильные

то есть в join задать условие ?

че получается, все время уходило на парсинги?

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

нет

уходило совсем не на то что требовалось сделать

отдельное спасибо!

я бы для тестов добавил в условия status='0'  и индекс на него составной, типо зачем обновлять то что уже в правильном статусе

ща гляну есть ли там вообще он

составной с чем ты имеешь ввиду ?

с id ?

могу конечно расписать что происходило, но тут основной источник зла это ОРМ, он
1. лепит хрен пойми какие запросы, совсем не то что мы хотим, в частности тут был LEFT JOIN
2. ОРМ поощеряет императивный подход программирования, вместо декларативного который заложен в SQL и отсюда проблемы:
- логических операторов в таком годе гораздо больше
- потребление ресурсов крайне высокое из-за постоянного обмена запросами и данными между клиентом (в нашем случае php) и БД
- ну и следствием предыдущего пункта, на ранней стадди проекта (когда эта оптимизация оч далеко преждевременна) вырастает куча костылей (очереди, кэширование и т.д.) которые ещё сильнее тормозят всё

option_id,status

наверное так

ok

так прикол в том, что апдейт с pma выполенялся 30 сек, причем тут орм?

условие надо, а вот индекс совершенно излишний и будет только ухудшать ситуацию

ребят, кто-нить работал с over()?

ну да, я же сравнивал что около 2х секунд разница была между орм и нативным

дак ты выполнял не запрос а какое-то недоразумение сгенерированное ОРМом вот в этом и проблема