Очень медленный запрос MySQL для 2,5 миллионов таблиц строки
Возможное решение с чистым css!
@-webkit-keyframes fade-in{
from{
opacity:1;
top:0px;
}
to{
opacity:0;
top:-5px;
}
}
.text-animated-one{
display:inline;
position:relative;
top:0px;
-webkit-animation:fade-in 1s infinite;
}
.text-animated-two{
opacity:0;
display:inline;
position:relative;
margin-left:-56px;
-webkit-animation:fade-in 1s infinite;
-webkit-animation-delay:0.5s;
}
.aggettivi{
display:inline;
width:100px;
height:100px;
}
8 ответов
Это уже относительно хорошо. Снижение производительности заключается в том, что запрос должен сравнивать 270404 varchars на равенство для COUNT (DISTINCT (email)) , что означает, что необходимо прочитать 270404 строки.
Вы можете произвести подсчет быстрее, создав индекс покрытия. Это означает, что фактические строки не нужно читать, потому что вся необходимая информация присутствует в самом индексе.
Для этого измените индекс следующим образом:
KEY `type_4` (`type`,`play_date`, `email`)
Я был бы удивлен, если бы это немного не ускорило процесс.
(Спасибо MarkR за правильный термин.)
Попробуйте указатель на play_date, введите (аналогично type_4, только перевернутые поля) и посмотрите, поможет ли это
Существует 4 возможных типа, и я предполагаю, что 100 возможных дат. Если в запросе используется тип play_date index, он в основном (не на 100% точный, но общая идея) говорит.
(A) Find all the Play records (about 25% of the file) (B) Now within that subset, find all of the requested dates
Путем обращения индекса, подход является
> (A) Find all the dates within range > (Maybe 1-2% of file) (B) Now find all > PLAY types within that smaller portion > of the file
Надеюсь, что это помогает
Вероятно, ваша индексация настолько хороша, насколько это возможно. У вас есть составной индекс для двух столбцов в вашем , где предложение и объяснение , которое вы опубликовали, указывают на то, что он используется. К сожалению, 270 404 строки соответствуют критериям в предложении where , и все они должны быть учтены. Кроме того, вы не возвращаете ненужные строки в списке select .
Я бы посоветовал агрегировать данные ежедневно (или ежечасно, или что-то еще) и кэшировать результаты. Таким образом вы можете мгновенно получить доступ к слегка устаревшим данным. Надеюсь, это приемлемо для ваших целей.
Извлечение электронной почты в отдельную таблицу должно быть хорошим приростом производительности, поскольку подсчет отдельных полей varchar должен занять некоторое время. В остальном - используется правильный индекс, а сам запрос максимально оптимизирован (за исключением электронной почты, конечно).
Часть COUNT (DISTINCT (email)) - это бит, который вас убивает. Если вам действительно нужны только первые 2000 результатов из 270 404, возможно, будет полезно подсчитывать электронные письма только для результатов, а не для всего набора.
SELECT date, COUNT(DISTINCT(email)) AS count
FROM log,
(
SELECT play_date AS date
FROM log
WHERE play_date BETWEEN '2009-02-23' AND '2020-01-01'
AND type = 'play'
ORDER BY play_date desc
LIMIT 2000
) AS shortlist
WHERE shortlist.id = log.id
GROUP BY date
В долгосрочной перспективе я бы рекомендовал создать сводную таблицу с первичным ключом play_date и подсчетом отдельных писем.
В зависимости от того, насколько он вам нужен - разрешите ему обновляться ежедневно (по play_date) или в реальном времени с помощью триггера в таблице журнала.
Существует большая вероятность, что сканирование таблицы будет быстрее, чем случайное доступ к более чем 200 000 строк:
SELECT ... FROM log IGNORE INDEX (type_2,type_4,type_result) ...
Кроме того, для больших сгруппированных запросов вы можете увидеть лучшую производительность за счет принудительной сортировки файлов, а не группы на основе хеш-таблицы (поскольку, если это окажется, потребуется больше, чем tmp_table_size или max_heap_table_size производительность падает):
SELECT SQL_BIG_RESULT ...