У меня есть этот странный запрос
SELECT t.something_id, t.platform, t.country, SUM(t.amnt) AS amountz
FROM ( SELECT something_id, platform, country, 1 AS amnt
FROM log_table
WHERE target_date = '2018-02-09'
GROUP BY (unique_key) ) t
GROUP BY t.something_id, t.country, t.platform
В таблице журнала есть уникальные игроки и счетчик, где, если у игрока есть несколько сеансов - он обновляется.Он работает на основе уникального индекса, в который каждый день вставляется отдельная строка для уникального пользователя, чтобы мы могли анализировать данные. В этот момент таблица довольно сильно выросла, и выполнение этого запроса для подсчета уникальных пользователей вчерашних дней является довольно сложной задачей..
Выполнение расширенного запроса объяснения дает мне такой результат:
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | | | |
|---- |------------- |----------- |------- |--------------- |------------------ |--------- |----------- |----------- |---------- |------------ |-------- |---------- |------- |
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 114441375 | 100.00 | Using | temporary;| Using | filesort |
| 2 | DERIVED | log_table | index | NULL | idx_multi_column | 944 | NULL | 114441375 | 100.00 | Using | where; |Using | index |
моя структура:
| Name | Type |
|------------- |-------------- |
| stat_id | int(8) |
| metric | tinyint(1) |
| platform | tinyint(1) |
| something_id | varchar(128) |
| target_date | date |
| country | varchar(2) |
| amount | int(100) |
| unique_key | varchar(180) |
| created | timestamp |
| modified | timestamp |
индекс, который я использую: idx_multi_column
= unique_key,target_date,country,platform,something_id
Я знаю, что первый выбор, который вкладывает второй выбор, использует временное хранилище и из-за количества строк, что сильно замедляет работу.Есть ли способ улучшить это?