Задержка для некоторых активных пользователей на странице платежных данных

Question

Задержка для некоторых активных пользователей на странице платежных данных

0

Я разработал страницу сводки счетов, используя mysql + php.

существует много пользователей: (1M)
легкий пользователь: каждый имеет запись менее 10K: пользователи 0.99M.
тяжелый пользователь: каждый имеет запись за 1M

SQL:

SELECT SUM(value_a) A, SUM(value_b) B, SUM(value_c) C
FROM  daily_data_sep_2010
WHERE  user_id='<user_id>'
AND type
IN (
  'type_a',  'typeb'
 )
AND publish_date
BETWEEN  '<start_date>'
AND  '<end_date>'
GROUP BY publish_date
ORDER BY publish_date DESC

Тип таблицы daily_data_sep_2010 - это MyISAM

Существует несколько типов одинаковых запросов, но SUM (значение_a) A, SUM (значение_b) B, SUM (значение_c) C являются одинаковыми (равными) Условия "WHERE", "GROUP BY" не одинаковы.

Этот экран очень медленный для тяжелых пользователей. У вас есть хорошие решения?

объясните здесь

| daily_data_sep_2010 | ALL | ОСНОВНОЙ, user_id_key, тип, PUBLISH_DATE |||| 1059756 | Использование где; Использование временных; Использование filesort |

Я думаю, размер строки слишком велик для суммы. поэтому я с нетерпением жду других решений (Hadoop?)

freddiefujiwara 20 окт. 2010, в 01:53

Источник

Теги:

php

mysql

sql

3 ответа

0

MySQL 5.1.3 Сервер поддерживает разделение. вы можете ссылаться на разделение mysql, url http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

Sam 20 окт. 2010, в 00:13

0

Вы можете попробовать выполнить запрос с помощью команды explain.

Однако я бы предположил, что добавление одного из этих индексов поможет (в зависимости от того, как часто встречаются ряды с соответствующими типами):

user_id, type, publish_date, value_a, value_b, value_c
user_id, publish_date, type, value_a, value_b, value_c

Это должно позволить ему проконсультироваться только с индексом для вашего запроса (уменьшив количество прочитанных страниц), а также разрешить сканирование диапазона индексов (или, что бы он ни называл MySQL), для создания фактических данных.

Другой вариант - запустить запланированный (возможно, ночной?) процесс для создания данных для ваших "тяжелых" пользователей и использовать эти данные при показе отчетов.

Jonathan Rupp 19 окт. 2010, в 20:52

0

Спасибо, что ответили, и результат объяснения добавлен. Но я думаю, что размер строки слишком велик для суммы. так что я с нетерпением жду других решений (Hadoop?)
freddiefujiwara 19 окт. 2010, в 23:34

Ещё вопросы

Спасибо, что ответили, и результат объяснения добавлен. Но я думаю, что размер строки слишком велик для суммы. так что я с нетерпением жду других решений (Hadoop?)

Tim · Accepted Answer · 2010-10-19T21-24-00.000Z

Любая разница, если вы создаете составной индекс на (userid, type) и делаете это:

       where userid = ? and type in (a,b)
       and publish_date between...
       group by publish_date

Огромное спасибо . мое объяснение
| Daily_data_sep_2010 | ссылка | ОСНОВНОЙ, user_id_key, тип | user_id | 4 | Const | 30297 | Использование где; Используя временные; Использование сортировки файлов |