По мессенджерам или скайп

как раз этот промежуток не так долго выполняется, т.к. это 1 день.

короче чо оптимальнее click хаус или вертика?

0) перепиши запрос так: SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, SUM(click_amount) AS clicks, ROUND(SUM(click_amount)/SUM(visit_amount)*100) AS prod, SUM(is_bot) AS bots, SUM(is_proxy) AS proxies, SUM(is_no_cookie) AS nocookies, FROM_UNIXTIME(TIME, "%H") AS hour FROM log_visit WHERE time BETWEEN 1539129600 AND 1539215999 GROUP BY FROM_UNIXTIME(TIME, "%H") ORDER BY FROM_UNIXTIME(TIME, "%H") DESC, raws DESC 1) в таком раскладе ЕДИНСТВЕННЫЙ критерий оптимизации -- это выборка диапазона по time. Нужен любой индекс по time или где это первая колонка. Для больших диапазонов типа месяца, недели, где более 5% записей таблицы, этот индекс всё равно бесполезен. 2) GROUP BY оптимизируется только выделением большего количества памяти под сервак, на кэш (для Inno) и на буфера для обработки (какие это буфера -- не знаю, надо искать)

Также ещё одна непонятка. Группируешь ты по ЧАСУ. А данные запрашиваешь ЗА НЕДЕЛЮ. Разные часы суток разных дней должны идти В ОДНУ ГРУППУ ИЛИ В РАЗНЫЕ?

я понял уже что проще перенести таблицу

За неделю группировка по дате

ща

И ещё СОВСЕМ непонятно, на кой фиг почасовые раскладки ЗА МЕСЯЦ? ЭТо 24 * 30 = 720 записей. Кому такое надо ?

потому что минимальный шаг анализа 1 час

вот за неделю я имел виду запрос: SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, SUM(click_amount) AS clicks, ROUND(SUM(click_amount)/SUM(visit_amount)*100) AS prod, SUM(is_bot) AS bots, SUM(is_proxy) AS proxies, SUM(is_no_cookie) AS nocookies, FROM_UNIXTIME(TIME, "%e %M") AS DAY FROM `log_visit` WHERE `time` BETWEEN 1535760000 AND 1536501600 GROUP BY `day`

Кто будет анализировать 750 записей? Никому это не надо.

А если там 10 тонн джаваскрипта у клиента с кучей логики, построением графиков на HTML5 в 3D и VR?

А если там 10 тонн джаваскрипта у клиента с кучей логики, построением графиков на HTML5 в 3D и VR?

0) перепиши запрос так: SELECT SUM(visit_amount) AS raws, COUNT(visit_amount) AS uniques, SUM(click_amount) AS clicks, ROUND(SUM(click_amount)/SUM(visit_amount)*100) AS prod, SUM(is_bot) AS bots, SUM(is_proxy) AS proxies, SUM(is_no_cookie) AS nocookies, FROM_UNIXTIME(TIME, "%H") AS hour FROM log_visit WHERE time BETWEEN 1539129600 AND 1539215999 GROUP BY FROM_UNIXTIME(TIME, "%H") ORDER BY FROM_UNIXTIME(TIME, "%H") DESC, raws DESC 1) в таком раскладе ЕДИНСТВЕННЫЙ критерий оптимизации -- это выборка диапазона по time. Нужен любой индекс по time или где это первая колонка. Для больших диапазонов типа месяца, недели, где более 5% записей таблицы, этот индекс всё равно бесполезен. 2) GROUP BY оптимизируется только выделением большего количества памяти под сервак, на кэш (для Inno) и на буфера для обработки (какие это буфера -- не знаю, надо искать)

Чего бы тогда просто не выкачивать всю таблицу, и агрегировать на клиенте через JS?

Чего бы тогда просто не выкачивать всю таблицу, и агрегировать на клиенте через JS?

переписал, но как я и говорил - выполение в три раза дольше, хоть он и логически правильнее :)

Т.е. тебе правильный запрос не нужен, нужен быстрый ?

Ну ладно тады успехов.

мне нужен выход из сложившейся ситуации

мне нужен выход из сложившейся ситуации

Потому что пользователю не нужно вываливать агрегации месячных данных поминутно, почасового и пр.

Дома работать уныло и скучно

Гайз, не подскажете типовую схему БД для склада, со случаем когда товары имеют срок годности и возможны приход, списание, перемещение? Чет у меня какая-то громоздкая схема получается, кажется что должно быть все проще

Гайз, не подскажете типовую схему БД для склада, со случаем когда товары имеют срок годности и возможны приход, списание, перемещение? Чет у меня какая-то громоздкая схема получается, кажется что должно быть все проще

вот такая схема пока выходит, учитывает возможность отменить проведение документа

Товары p_id Склады s_id Документы d_id s_id stage_id ДокументыТовары d_id p_id count ended_at ДокументыТоварыПроведение dtp_id stage_id d_id p_id count ended_at ТоварыСклады p_id s_id dtp_id count

Привте, есть вопрос, нужно сделать поиск (MySQL) в таблице по id, делаю через like, но штука в тому что если например я ввоожу %71% то ищет результаты, а если %714%, то вообще 0, хотя в базе есть 714б 714 и так далее

Какой тип данных у поля id?

Привте, есть вопрос, нужно сделать поиск (MySQL) в таблице по id, делаю через like, но штука в тому что если например я ввоожу %71% то ищет результаты, а если %714%, то вообще 0, хотя в базе есть 714б 714 и так далее

> id > like да вы, батенька, тот еще месье

> id > like да вы, батенька, тот еще месье

> id > like да вы, батенька, тот еще месье

нигде вроде и не написано что id здесь какой-то ключ, хотя бы пусть и суррогатный. может у них по style guide все ключи это entity_id например. А id это... ну iнформация о doкументе

нигде вроде и не написано что id здесь какой-то ключ, хотя бы пусть и суррогатный. может у них по style guide все ключи это entity_id например. А id это... ну iнформация о doкументе

Так и есть, id просто инфо

Какого типа id ?

Integer

Ну, и чё ты нам будешь затирать ещё?

show create table; select count(*) from table where id = '714б 714 ';

Просто спросил, а говна...

в mariadb в огромную myisam таблицу всегда в конец делаются инсерты в большом количестве скажем с 10 сессий. В какой-то момент, когда нагрузка становится невыносимой, происходит следующее. Лочится таблица, висит инсерт и не может заинсертится, дальше приложуха, которая создала сессию, киляет ее через 20 сек. В мускуле я вижу эту сессию как "Unlocking tables", но уже killed. И, судя по show processlist она так продолжает висеть в течение 120-130 секунд. Соотвественно все остальные сессии от других аппликашек висят с инсертами в статусе System lock (20 сек пока их не кильнут и так по кругу)

Может быть, дело в движке таблицы? ???