слушай, нафига мне цыгане в большом куше, если я вполне знаю кто это такие, потому что этих тварей был полный табор возле села моей бабушки. Пока их вечерком тупо не спалили к херам собачьим

ну то что они асоциальны и не интегрирукются - это факт, да

чёто вас не туда несёт опять

intellectus — ощущение, восприятие, разумение, понимание, понятие, рассудок

ну то что они асоциальны и не интегрирукются - это факт, да

они вполне социальны

вопрос в том - имеют ли они правд на это

в своей среде

ты про внутреннюю социальность

Давайте прекращать в общем это

флуд

что ты знаешь о флуде, фоли

давайте багарта в др забаним 8)

падарок

та даа)

и фолли

happy birthday

пусть идёт бухает уже

я на низком старте

О! У тебя еще и ДР! ) Тьфу, СхеппиБездеем тебя.

аха я польщён

О! У тебя еще и ДР! ) Тьфу, СхеппиБездеем тебя.

присоединяюсь!

я на низком старте

яга? ?

это чёт из другой культуры

я по классике - новое дерьмо опасно

(с) угадай кто :)

старое - родное?)

работает?

а что дает этот оборот, запрос не ломает, а что дает? ORDER BY MIN(`message`.`id`) DESC

кубинский ром...

кубанский

а что дает этот оборот, запрос не ломает, а что дает? ORDER BY MIN(`message`.`id`) DESC

min - минимальное значение

а что дает этот оборот, запрос не ломает, а что дает? ORDER BY MIN(`message`.`id`) DESC

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

мин - агрегирущая функция

грязный фикс

блядь, одна г

там ещё прикол есть

если у тебя 2 меседжа будет с одинаковым текстом - они обхеденятся

поэтому в группировку надо и айди добавлять

мин - агрегирущая функция

так и это решение идет SELECT text AS command ,COUNT(*) AS total FROM message WHERE message.date >= :startPeriod AND message.text LIKE "/%" GROUP BY message.text,message.id ORDER BY message.id DESC ну ок, оставлю два этих изменения

ну надо вообще смотреть, что тебе нужно

SELECT text AS command ,COUNT(*) AS total FROM message WHERE message.date >= :startPeriod AND message.text LIKE "/%" GROUP BY message.text,message.id ORDER BY message.id DESC

во как надо)

message.text LIKE "/%" ненужная тяжёлая операция скорее всего. майскул же не умеет индексы строить по результатам лайков

если добавить ид в группировку - есть шанс, что он будет не так группировать, как надо

но тебе и так пойдёт

хм

так и это решение идет SELECT text AS command ,COUNT(*) AS total FROM message WHERE message.date >= :startPeriod AND message.text LIKE "/%" GROUP BY message.text,message.id ORDER BY message.id DESC ну ок, оставлю два этих изменения

два решения не надо!

смотря какой индекс поди

но вообще да

либо мин олибо группа

интересно

чё эксплейн скажет

по идее первая буква нужна же

смотря какой индекс поди

уокнкретно это в индексе найдётся. но операция всё равно не быстрая

если процент стоял бы первым - совсем печально бы было

но если это статика значит её надо считать заранее или индексировать

уокнкретно это в индексе найдётся. но операция всё равно не быстрая

если муська распарсит, что нужна именно первая буква

а то ведь и хуй положить может

по идее первая буква нужна же

пройдёт

если поле проиндексировано конечно

либо мин олибо группа

ооо, мин идет даже лучше, он сумирует

ненене

суммирует sum

ERROR: S client not available

а то ведь и хуй положить может

так индекса специального ж не будет

ооо, мин идет даже лучше, он сумирует

)))))))))))))))))))))

я уже сказал

если у тебя будет 10 пустых меседжей ии 1 не пустой - у тебя будет всего 2 "сообщения"

1 пустой и 1 не пустой

может ему так и надо

или скажем будет 1млн "test" а на выходе получишь только 1

ему ид нужно только для сортировки (нахуя вообще?)

ему ид нужно только для сортировки (нахуя вообще?)

есть смысл обычно. это сортировка по времени по сути

причём, быстрее чем по времени

хз

имхо выкинуть к хуям

не похоже

вот у тебя статсов целая куча и это косяк

что ему вообще сортировка нужна

но что тебе нужно это ты решай

:)

что ему вообще сортировка нужна

не исключено

этот всё, следующего поциента заносите

count(*) в таком запросе - норм? По идее лучше уточнять поле...

count(*) в таком запросе - норм? По идее лучше уточнять поле...

а если таблица огромная? и полей дохера?

та пофиг

?

сколько этот каутн будет обрабатываться?)

та пофиг

и так сойдет

10 минут обрабатывался как-то один запрос)

на прод самое то такие запросы)

Никак не оптимизируются автоматом?

пистолетом