2012-06-22 4 views
0

Вот мой пример запроса:MySql получить ранг в запросе

SELECT userid,count(*) 
FROM hits 
GROUP BY userid 

Мой стол что-то вроде этого

ид | userid | время ... и т. д.

Где id является основным ключом, и я использую эту таблицу для хранения каждого посещения на странице. Это означает, что мой стол имеет 200 000 строк.

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

Я знаю, что есть много вопросов, как это, но они не такие же, потому что

  1. Мой запрос имеет группу по
  2. Я попытался довольно много ответов здесь некоторые даже не вернуть ничего в то время как другие принимают 5-10 мин. Мне нужно, чтобы это было быстрее.

для любых дальнейших сомнений пожалуйста разъясняют в комментариях

Благодарности

+0

Вы пытались вставить инструкции SELECT? – hjpotter92

+0

да. Он никогда не давал ответа, что более 20 000 строк возвращаются этим запросом. Итак ..... – kritya

ответ

0

Count/Группа по в запросе, который, как ожидается, возвращать несколько строк будет прогрессивно медленнее, поскольку запрос будет по-прежнему должны коснуться каждой строки в таблице. Как правило, если вы ожидаете часто делать подобные отчеты, и вы ожидаете, что ваша таблица будет продолжать расти, вы должны начать переносить это значение в кешированное значение (так что вы должны хранить каждый результат все же, но вы также должны добавить к счетчику на это пользовательская запись пользователя). Конечно, это также ставит вопрос о том, есть ли у вас индекс в вашем столбце user_id и внешний ключ в таблице ваших пользователей, что должно значительно ускорить этот запрос.

+0

Я хочу это в реальном времени, поэтому я хочу иметь запрос, который будет работать. Даже если я буду следовать этому методу, который по-прежнему означает использование больших ресурсов системы. – kritya

+0

@kritya \t У вас не будет использования больших ресурсов, если вы сделаете это правильно. Каждый раз, когда кто-то посещает, увеличивайте их число плюс вставляйте строку, 1 инструкция обновления не должна испортить использование, если вы не делаете что-то невероятно неправильно. И если вам не нужна подробная информация о временной метке, не вставляйте другую строку. Хотя вы никогда не отвечали, есть ли у вас индекс для userid, который должен быть обязательным для этого запроса. Запрос, который исследует сотни тысяч строк и возвращает строки 20k, будет медленным, и индекс улучшит это, но вы все еще ограничены логом (n) из всех строк. – hsanders

+0

@kritya Я бы также добавил, что иногда ваши первоначальные варианты дизайна неверны. Это один из таких случаев. Одно из приложений, над которыми я работаю, обрабатывает 10M строк данных/день и делает отчеты на основе подсчета строк для определенных элементов, мы никогда не сможем сделать это с помощью описанного вами запроса, поэтому мы будем свертывать его и кэшировать в таймфрейме. Большим наборам данных иногда требуется кэширование, чтобы предлагать своевременные ответы. Некоторые запросы не могут быть оптимизированы в дальнейшем. – hsanders