не могу повернуть запрос так чтобы для item выводить минимальную из calc_price

если поставить группировку по i.id, то сумму посчитает сложив все цены

оберни в подзапрос и примени агрегацию ещё раз

SELECT t.item, MIN(t.calc_price) FROM ( SELECT p.item, p.id, SUM(IF(i.collection_id = 1, pi.cost_moscow, pi.cost) * pp.count) as calc_price FROM prices p JOIN items i ON i.id = p.item JOIN pr_price pp ON pp.price = p.id AND pp.count > 0 JOIN pr_items pi ON pi.id = pp.pr2_item AND pi.type <> 4 WHERE p.spp_id = 0 GROUP BY p.id ORDER BY p.item) as t GROUP BY t.item

так?

вроде считает. Это норм способ7

это норм способ

Спасибо!

а если сразу заапдейтить поле calc_price в табличку items по t.item ?

так а как ты заапдейтиш сумму, если ты ее из нескольких строк собираешь

ну там же 1 айди одна сумма

ага, а собираешь ты его из 3 строк

условно

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

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

/spam

Этот вопрос меня мучал ооочень долго, и до сих пор терзает как лучше делать Смотри вот Вот есть в БД таблицы state(id, name) lake(id, state.id , name) (у одной области есть много озер) мне нужно сделать выборку из бд в таком виде [ [ name => state_1, lakes => [ // можно и lake [ name => lake_1, ] [ name => lake_2, ] [ name => lake_n, ] ] ], [ name => state_2, lakes => [ [ name => lake_1, ] [ name => lake_2, ] [ name => lake_n, ] ] ], [ name => state_3, lakes => [ [ name => lake_1, ] [ name => lake_2, ] [ name => lake_n, ] ] ], ] я групирую в строку по разделителю (group_concat()), а на сервере эту строку разбиваю по разделителю в массив ( explode(var, ',') ) Подробнее: https://tagmycode.com/snippet/7091

PHP

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

т.е. Это невозможно? А в postgresql возможно\?

это возможно только это говнокод

https://telegram.me/telegidka — самые полезные и интересные каналы на просторах Телеграм. Присоединяйся.

https://telegram.me/telegidka — самые полезные и интересные каналы на просторах Телеграм. Присоединяйся.

spam

https://telegram.me/telegidka — самые полезные и интересные каналы на просторах Телеграм. Присоединяйся.

/spam

Утречка всем. Вопросец такой: Обычный такой запрос UPDATE `videos_stats` SET `current_shows`=`current_shows`+1 WHERE (`image_id` IN (27605, 24818, 24564, 26009, 24234, 27666, 26313, 27552, 23075, 24697, 25386, 26729, 24191, 24016, 27545, 26804, 20854, 21848, 23620, 25917, 24573, 24597, 24851, 27285, 27292, 27518, 23554, 24021, 24881, 27221)) AND (`category_id`='13') Периодически выдает ошибку Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction При это транзакций с таблицей никаких нет. Двиг InnoDB бд MySql. Чот не могу нагуглить как решить проблему, подскажите в каком направлении копать, или решение =)

Show engine innodb status с секцией last detected deadlock скидывай

Движок innodb транзакционный, даже если ты не делаешь явный start transaction это все равно будет транзакция

ниче не показывает, пусто

Show engine innodb status с секцией last detected deadlock скидывай

зашарил скрин. ВИдно ага какой запрос локнул, и что делать в этой ситуации не понятно (обновление кликов/показам кроном делается,т.е. другое соединение вообще)

У тебя второй запрос блочит всю таблицу

Ну в общем дедлоки - это неизбежное следствие MVCC. Приложение в любом случае должно проверять и обрабатывать такие ошибки, иначе оно криво написано

Ты можешь минимизировать их в своём конкретном случае. Но обработка ошибок все равно должна быть

Оно и так криво написано

Не должно быть таких запросов

Второй запрос можно посчитать на лету, его не обязательно сохранять

https://telegram.me/telegidka — самые полезные и интересные каналы на просторах Телеграм. Присоединяйся.

/SPAM

А где второй? Я с телефона, что-то не разгляжу

Ищи под (2) transaction

Там еще разделяемая блокировка на строки из этой таблицы, возможно там что то еще перед этим апдейтом выполняется

Именно перед вторым апдейтом

Второй запрос можно посчитать на лету, его не обязательно сохранять

т.е. вместе с апдейтом просмотра или клика обновлять сразу соотношение? Оно будет корректно работать в 1 запросе? (имею в виду по актуальным данным, клик и просмотр изменились же)

Я имел ввиду что соотношение вообще не стоило заводить в отдельной колонке

И считать его по всей таблице

т.е. при выборке его считать?

Да

по это соотношению индекс есть, т.е. основная сортировка

Зачем хранить избыточные данные, и еще сервер насиловать подобными запросами

так при каждом запросе и так считать будет и сортировать

разве нет?

Будет, но если у тебя с индексами все в порядке это будет очень быстро

в mysql 5.7 есть ещё generated columns

вот для таких вещей, в том числе

Кстати да

а вообще, я думаю дедлоки пропадут, если id-шники в длинном UPDATE сортировать. а во втором использовать ORDER BY. но это не отменяет всего остального сказанного

а вообще, я думаю дедлоки пропадут, если id-шники в длинном UPDATE сортировать. а во втором использовать ORDER BY. но это не отменяет всего остального сказанного

id составной из 3-х колонок, хз как там че сортировать

Будет, но если у тебя с индексами все в порядке это будет очень быстро

total_clicks и total_shows тоже вычисляются по всей таблице разом в томже кроне, но они не индексные

Это не играет роли

У тебя вся таблица обновляется

https://pastebin.com/eVdYDnhZ

У тебя вся таблица обновляется

да, 2 раза ;[

Опа

Ключики

Со связанными ключами таблицами что то перед обновлением выполняется?

нет, они просто для контроля, ну и при удалении используются

в mysql 5.7 есть ещё generated columns

почитал, вроде как раз то. Но будет ли оно работоать в случае когда 1 генерированная колонка будет вычисляться из двух других генерированных? ))

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

Выйгрыш на спичках

У тебя проблема с доступом к данным

А не с расчётом колонки

почитал, вроде как раз то. Но будет ли оно работоать в случае когда 1 генерированная колонка будет вычисляться из двух других генерированных? ))

да

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

очень рекомендую DOUBLE вместо FLOAT

очень рекомендую DOUBLE вместо FLOAT

8 байт против 4... точность не так важна

сэкономив 4 байта, ты получишь примерно на 5% меньше размер таблицы, но кучу потенциальных проблем взамен

я не знаю предметной области. но лучше FLOAT вообще избегать. такой себе тип данных, не о чём

ясно, спасибо )

чет подумал, если есть индекс по генерированной колонке, как оно себя вести будет в этом случае? При каждом апдейте перестраивать?

точно так же, как и с обычными колонками. обновлять индекс, если значение в колонке изменилось, иначе не трогать

т.е. частое обновление колонки крайне не желательно... В доке написано что индекс по такой колонке только в памяти хранится

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

не знаю, что понимается под "крайне нежелательно". у обновления индекса есть стоимость, да