Как ускорить Группирование по запросу

Question

Как ускорить Группирование по запросу

0

У меня есть запрос mysql, который занимает 30 секунд. в таблице содержится более 3 миллионов строк

вот структура db:

text (VARCHAR(64)), 
kpi1 (INT), 
kpi2 (INT), 
position (DECIMAL),
date(DATE)
device (VARCHAR(32))

Вот запрос:

select date, sum(kpi1), sum(kpi2) FROM  'table_name' GROUP BY date ;

Объяснить метод дает мне этот результат:

ID  | select type   | table        | partitions | type  | possible_keys  | key  | key_len | ref  | rows    | filtred | extra
1   | SIMPLE        | table_name   | NULL       | index | UNIQUE,DATE    | DATE | 3       | NULL | 3316480 | 100.00  | NULL

У меня есть указатель на дату.

Здесь результат с профилированием:

mysql> show profile for query 1;
+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| starting             |  0.000080 |
| checking permissions |  0.000011 |
| Opening tables       |  0.000021 |
| init                 |  0.000023 |
| System lock          |  0.000011 |
| optimizing           |  0.000007 |
| statistics           |  0.000021 |
| preparing            |  0.000019 |
| Sorting result       |  0.000007 |
| executing            |  0.000005 |
| Sending data         | 32.814836 |
| end                  |  0.000011 |
| query end            |  0.000009 |
| closing tables       |  0.000009 |
| freeing items        |  0.000082 |
| cleaning up          |  0.000013 |
+----------------------+-----------+
16 rows in set, 1 warning (0,00 sec)

Любая идея?

Dany M 25 апр. 2018, в 13:40

Источник

1

Для запроса нужен индекс (date, kpi1, kpi2)
Raymond Nijland 25 апр. 2018, в 11:26
0

@NB после группировки не возвращает много строк. только 345 возвращены
Dany M 25 апр. 2018, в 11:32
0

Это полезная информация, и да, предложение Раймонда имеет больше смысла. Чтобы получить больше информации из MySQL, вы должны использовать профилирование, чтобы определить, является ли узкое место из-за жесткого диска. SET PROFILING = 1; <your query>; SHOW PROFILE FOR QUERY 1 а затем проверить, что он говорит, он показывает каждый шаг от открытия файлов до записи в сокет. Вы вообще innodb_buffer_pool_size переменную innodb_buffer_pool_size ?
N.B. 25 апр. 2018, в 11:35
0

@NB Я обновил вопрос с результатом профилирования. узкое место, кажется, заключается в отправке данных ... Каков хороший конфиг для innodb_buffer_pool_size ?
Dany M 25 апр. 2018, в 11:48
0

innodb_buffer_pool_size контролирует, сколько памяти MySQL использует для хранения индексов. Вы хотите, чтобы это было как можно выше, в идеале размер вашего набора данных. Обычная практика - иметь 90% доступного оперативного памяти, посвященного MySQL. Этот параметр перемещает ввод / вывод с диска в оперативную память, что заставляет MySQL работать. Теперь, что касается профилировщика - в некоторых версиях MySQL была ошибка, когда время фактически было временем от предыдущего шага. Это означает, что executing части занимает время, что имеет смысл, поскольку сортирует 3,3 миллиона записей. Увеличение пула буферов должно значительно ускорить эту операцию.
N.B. 25 апр. 2018, в 14:27
0

я установил buffer_size на 1G и разделил время работы на 2. но это все еще огромное время и не является долгосрочным решением, потому что размер базы данных со временем будет увеличиваться. сейчас размер таблицы составляет около 211Mo, так что я думаю, что у меня достаточно оперативной памяти, выделенной для этого ... какая версия Mysql исправляет эту ошибку? может быть, я просто должен обновить?
Dany M 25 апр. 2018, в 14:54

Показать ещё 4 комментария

Теги:

mysql

group-by

1 ответ

Ещё вопросы

Для запроса нужен индекс (date, kpi1, kpi2)
@NB после группировки не возвращает много строк. только 345 возвращены
Это полезная информация, и да, предложение Раймонда имеет больше смысла. Чтобы получить больше информации из MySQL, вы должны использовать профилирование, чтобы определить, является ли узкое место из-за жесткого диска. SET PROFILING = 1; <your query>; SHOW PROFILE FOR QUERY 1 а затем проверить, что он говорит, он показывает каждый шаг от открытия файлов до записи в сокет. Вы вообще innodb_buffer_pool_size переменную innodb_buffer_pool_size ?
@NB Я обновил вопрос с результатом профилирования. узкое место, кажется, заключается в отправке данных ... Каков хороший конфиг для innodb_buffer_pool_size ?
innodb_buffer_pool_size контролирует, сколько памяти MySQL использует для хранения индексов. Вы хотите, чтобы это было как можно выше, в идеале размер вашего набора данных. Обычная практика - иметь 90% доступного оперативного памяти, посвященного MySQL. Этот параметр перемещает ввод / вывод с диска в оперативную память, что заставляет MySQL работать. Теперь, что касается профилировщика - в некоторых версиях MySQL была ошибка, когда время фактически было временем от предыдущего шага. Это означает, что executing части занимает время, что имеет смысл, поскольку сортирует 3,3 миллиона записей. Увеличение пула буферов должно значительно ускорить эту операцию.
я установил buffer_size на 1G и разделил время работы на 2. но это все еще огромное время и не является долгосрочным решением, потому что размер базы данных со временем будет увеличиваться. сейчас размер таблицы составляет около 211Mo, так что я думаю, что у меня достаточно оперативной памяти, выделенной для этого ... какая версия Mysql исправляет эту ошибку? может быть, я просто должен обновить?

DRapp · Answer 1 · 2018-04-25T09-26-00.000Z

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

insert into MyDailySummaryTable 
   ( Date, kpi1Sum, kpi2Sum, numRecs )
   select date, 
          sum(kpi1) kpi1Sum, 
          sum(kpi2) kpi2Sum,
          count(*) numRecs
      FROM  
         'table_name' 
      where
         date < curdate()
      GROUP BY 
         date ;

затем на каждый день после начальной загрузки

insert into MyDailySummaryTable 
   ( Date, kpi1Sum, kpi2Sum, numRecs )
   select date, 
          sum(kpi1) kpi1Sum, 
          sum(kpi2) kpi2Sum,
          count(*) numRecs
      FROM  
         'table_name' 
      where
         date = date_add( curdate(), interval -1 day )
      GROUP BY 
         date ;

Если в поле "дата" также есть информация о временной отметке, вам может потребоваться отрегулировать запрос, чтобы игнорировать временные порции.

Затем, пытаясь запустить ваши итоги, вы можете просто запросить у MyDailySummaryTable напрямую и получить мгновенные результаты.

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

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