BoBka-altRUist
Новичок
Приветствую, у меня вопрос, есть таблица:
при входе пользователя на сайт, его ip проверяется в таблице за текущую дату если уже есть запись, то добавляется запись где uniq=0, если нет записи с таким ip то uniq=1
все остальные параметры user_id | val_1 | val_2 | val_3 записываются соответственно (они получены из строки запроса)
clicks - всего количество посещений с параметрами user_id | val_1 | val_2 | val_3
т.е. если составить уникальный id то он будет зависеть от этих полей:
ip+user_id+val_1+val_2+val_3
order - это факт создания заказа при посещении 1/0
status - это статус заказа 0/1/2/NULL
wm_total - сумма заказа если есть заказ сумма/NULL
после этого каждому пользователю системы (user_id) нужно показывать сумму количества уников, кликов, заказов и статусов заказов, сгруппированны по дате
также в этой выборке могут быть дополнительные условия по полям val_1 | val_2 | val_3 (их пользователь выбирает в фильтре)
по началу все работало быстро но когда размер этой таблицы стал около 8Гб (примерно 25 млн записей) такой запрос (по интервалу дат за месяц) блокирует базу, т.к. mysql создает временную таблицу для подсчета...
индексы по полям id | user_id | val_1 | val_2 | val_3 | date | uniq | order | status
да, т.к. в таблице есть статусы заказов через время в ней обновляются данные когда статус заказа меняется, это тоже создает доп. накладные расходы
скажите как это лучше организовать, да, возможно информацию по заказам нужно вынести в другую таблицу а в этой оставить id заказа, но при подсчете придется выбирать данные из двух таблиц и суммировать, не знаю добавит ли это скорости.
или вообще все неверно задумано?
Код:
id | date | user_id | val_1 | val_2 | val_3 | ip | clicks | uniq | order | status | wm_total
123 2015-10-20 23 456 657 879 127.0.0.1 5 1 1 2 100
124 2015-10-20 23 111 657 879 127.0.0.1 3 0 0 NULL NULL
125 2015-10-20 23 111 222 879 127.0.0.1 2 0 1 1 200все остальные параметры user_id | val_1 | val_2 | val_3 записываются соответственно (они получены из строки запроса)
clicks - всего количество посещений с параметрами user_id | val_1 | val_2 | val_3
т.е. если составить уникальный id то он будет зависеть от этих полей:
ip+user_id+val_1+val_2+val_3
order - это факт создания заказа при посещении 1/0
status - это статус заказа 0/1/2/NULL
wm_total - сумма заказа если есть заказ сумма/NULL
после этого каждому пользователю системы (user_id) нужно показывать сумму количества уников, кликов, заказов и статусов заказов, сгруппированны по дате
Код:
SELECT count(*) AS `date_count`, `date` AS `group_date`,
sum( if( status=0,1,0) ) as status0, # кол-во в обработке
sum( if( status=1,1,0) ) as status1, # кол-во принято
sum( if( status=2,1,0) ) as status2, # кол-во отмена
sum(uniq) as hit, # кол-во уников
sum( if( status IS NOT NULL,1,0) ) as status_all, # кол-во с любым статусом это общее кол-во заказов
sum( if( status=0,wm_total,0) ) as total0, # сумма в обработке
sum( if( status=1,wm_total,0) ) as total1, # сумма принято
sum( if( status=2,wm_total,0) ) as total2, # сумма отмена
sum( if( status IS NOT NULL,wm_total,0) ) as total_all # сумма в обработке
FROM `stat`
WHERE
( `date_day` >= '2015-10-01' AND `date_day` <= '2015-10-30' )
AND `user_id` = '23' # id пользователя чей запрос
GROUP BY group_date
ORDER BY `date_day` DESCпо началу все работало быстро но когда размер этой таблицы стал около 8Гб (примерно 25 млн записей) такой запрос (по интервалу дат за месяц) блокирует базу, т.к. mysql создает временную таблицу для подсчета...
индексы по полям id | user_id | val_1 | val_2 | val_3 | date | uniq | order | status
да, т.к. в таблице есть статусы заказов через время в ней обновляются данные когда статус заказа меняется, это тоже создает доп. накладные расходы
скажите как это лучше организовать, да, возможно информацию по заказам нужно вынести в другую таблицу а в этой оставить id заказа, но при подсчете придется выбирать данные из двух таблиц и суммировать, не знаю добавит ли это скорости.
или вообще все неверно задумано?
Последнее редактирование: