С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 03:47 |
То ли я не понимаю как работает sum, то ли какие-то баги мускуля
Идет первый запрос, количество кликов за текущие сутки:
>> SELECT sum(user_clicks) FROM users WHERE user_when > 1282712400
Возвращает 29516 (совершенно не риал - за все время у меня 70к)
Идет второй запрос, кол-во кликов за предыдущие сутки:
>> SELECT sum(user_clicks) FROM users WHERE user_when > 1282626000 && user_when < 1282712400
Возвращает 2469 (уже более реальные цифры)
В чем ллять разница?? вообще не могу въехать..
|
|
|
|
С нами с 13.01.10
Сообщения: 84
Рейтинг: 72
|
Добавлено: 26/08/10 в 11:37 |
ну судя по SQL разница в уловиях WHERE... а наасчет багов MySQL это вряд ли. А что за поле user_when? я так понял количество секунду? А что не просто дата?
|
|
|
|
С нами с 01.03.07
Сообщения: 304
Рейтинг: 223
|
Добавлено: 26/08/10 в 12:17 |
group by выставлять надо по правильным параметрам
|
|
|
|
С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 12:52 |
user_when - время, когда юзвер зашел на сайт, в юниксовом формате. Почему не таймштамп - сам уже не помню, но в таком виде был какой-то сакральный смысл.
Вот в том то и дело что когда пытаемся подсчитать за текущие сутки через WHERE user_when > 1282712400 вываливается полная херь(
|
|
|
|
С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 13:42 |
leroy_17 писал: | group by выставлять надо по правильным параметрам |
о, сейчас затестимс!
|
|
|
|
С нами с 01.03.06
Сообщения: 629
Рейтинг: 620
|
Добавлено: 26/08/10 в 14:01 |
group by имхо не нужен.
какая размерность поля хранящего время - INT -сколько = 9-10-11 ?
или на всякий случай посмотрите - нету ли в таблице невалидных данных - какой-то один счетчик зашкалил или есть записи на "год вперед".
|
|
|
|
С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 14:21 |
Heavy писал: | group by имхо не нужен.
какая размерность поля хранящего время - INT -сколько = 9-10-11 ? |
user_when int(15)
Heavy писал: |
или на всякий случай посмотрите - нету ли в таблице невалидных данных - какой-то один счетчик зашкалил или есть записи на "год вперед". |
Глянул - все ок вроде. От 1279062533 до 1282821657.
|
|
|
|
С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 14:26 |
Засунул груп. Уже с час весит 115 кликов, хотя гдет с 300 человек зашло (по крайней мере кликов 50-100 должно было набежать точно). Подозреваю что нужны еще какие-то параметры :
>> SELECT sum(user_clicks) FROM users WHERE user_when > " . $today . " GROUP BY user_id"
|
|
|
|
Чингачгук, вождь красноглазых
С нами с 14.05.04
Сообщения: 4744
Рейтинг: 1824
|
Добавлено: 26/08/10 в 14:41 |
Что-то не совсем понятно, что там в таблице вообще лежит - что в поле user_click и откуда оно берется? Я правильно понимаю, что там количество кликов от данного юзера, а user_when обновляется каждый раз, когда этот юзер кликает? Что это за юзеры, как ты определяешь, что именно за юзер кликнул? А так пока все "на деревню дедушке"
|
|
|
|
С нами с 27.05.10
Сообщения: 62
Рейтинг: 4
|
Добавлено: 26/08/10 в 15:21 |
Такс, в таблице есть:
user_id - автоинкримент, индекс, первичный
user_infohash - md5, в него уходит инфа о юзвере (айпи, агент и еще что-то там) - по нему определяю уникальность юзверя
user_referer - откуда пришел
user_clicks - количество кликов юзверя, ++ при каждом клике.
user_when - время когда пришел пользователь (в юниксовом формате) пишется один раз
|
|
|
|
Чингачгук, вождь красноглазых
С нами с 14.05.04
Сообщения: 4744
Рейтинг: 1824
|
Добавлено: 26/08/10 в 17:03 |
Ну а чего "такс"? Запрос выглядит совершенно нормальным, а вот гарантий, что ему скармливают валидные данные - нету никаких. Если ты на самом деле создаешь запись в первый раз, как юзер к тебе пришел - то ты в данной ситуации делаешь выборку не хитов за день, а сколько у тебя за тот день новоприбывших - старых юзеров, которые к тебе вернулись, ты уже не увидишь в селекте. Если же ты все-таки обновляешь user_when - то вылезать будет сумма всех хитов, за все время - от тех юзеров, которые один клик хотя бы за данный период выдали. Ну и за кадром остаются вопросы багов в коде, который уникальность юзера определяет, хэш создает. И еще мало ли что там за кулисами. Прежде чем предположить баги в MySQL, логично все-таки предположить сначала баг в своем коде.
По-хорошему тут 2 таблицы должно быть - в одной юзера, в другой - raw hits от них, с таймстемпом каждого и увязкой с таблицей юзеров через primary id таковой (веришь, нет - и работать будет быстрее). А так как сделано - это через жопу, и дальнейшие баги меня совершенно не удивили бы. К примеру, NULL values в колонке user_when
|
|
|
|
С нами с 01.03.07
Сообщения: 304
Рейтинг: 223
|
Добавлено: 26/08/10 в 18:08 |
ты бы сначала структуру выложил таблы
user_infohash - может лучше рассмотреть вариант с простановкой куков ? в большинстве случаев это будет лучше для подсчета юзеров, например если какой то трейд трафа.
Dr.Syshalt +1
|
|
|
|
С нами с 13.01.10
Сообщения: 84
Рейтинг: 72
|
Добавлено: 27/08/10 в 10:21 |
leroy_17 писал: | group by выставлять надо по правильным параметрам |
Нафига нужен group by? Это параметр нужен тольео если нуджно отгрупировать по полю. Проблема тут в том, что не верно выставлены условя в WHERE, вот и все. Как сделать их верными - это надо смотреть на данные в таблице.
|
|
|
|
С нами с 01.03.07
Сообщения: 304
Рейтинг: 223
|
Добавлено: 27/08/10 в 13:53 |
проблема тут в архитектуре таблицы.
про group by сказал до того как увидел структуру
|
|
|
|