Slava Rozhnev когда в таблице sc_proxy_request_log слишком много записей, данный запрос выполняется по 30 секунд.. точно такая же проблема в моём запросе который я указал)
Rsa97 Насколько я понимаю, данный запрос не правильно работает в моей задаче.
Есть таблица sc_proxy где хранятся все прокси.
Есть таблица sc_proxy_request_log в которой хранится лог запросов.
Задача получить Прокси из базы, при этом соблюдать условия:
IdSite - Это уникальный ID который указывает на лимит к конкретному сайту
3 - Это максимальное количество запросов которое нам подходит, т.е. если в sc_proxy_request_log есть 4 записи с этим прокси, то он не подходит под наше условие, т.к. не более чем 3 нам требуется.
Мой запрос фактически работает, но когда в sc_proxy_request_log становится слишком много записей, то выборка становится очень медленной.
Akina, если у нас лимит 5, то даже если 2000 записей подходят под наши условия, то мы должны взять первые 5, а остальные не трогать. Что значит критерий отбора? Критерий это и есть условие.
FanatPHP, всё при том же. У меня есть еще другие UPDATE запросы перед обновлением баланса для этого и нужна транзакция, поэтому и интересуюсь, получается блокировка от FOR UPDATE снимается после выполнения команды $DB_>commit();
FanatPHP, какое-то противоречие в вашем ответе)) Так блокирует транзакция или нет, лично я на практике тестировал - с транзакцией скрипт отрабатывает правильно.
то что из 5 заказов может быть мы примем только 3 НИКАК не объясняет, почему обновление баланса происходит $totalOrders раз, а не один
В чем смысл обновлять 3 раза, а не один?
а если будет 100 заказов - сто раз обновлять?
Вероятно вы правы, можно производить списание после выполнения цикла, но вопрос в данной теме у меня был другой.
Если вы советуете вытащить update баланса из цикла, то логично что и SELECT не нужно добавлять внутрь цикла чтобы запрашивался баланс каждый раз тоже не имеет смысла, верно?
