Оптимизация SQL-запроса для аналитики

Я реализовал систему аналитики, которая сейчас работает очень плохо. Чтобы объяснить это, я должен объяснить структуру таблицы запросовОптимизация SQL-запроса для аналитики

У меня есть две таблицы InnoDB

Table1: Содержит записи о почасовой статистике (stats_id, file_id, время) Table2: Содержит более 8 миллионов строк.

Таблица 2 Структура

full_stats (
    stats_id Int 
    file_id Int 
    stats_week Int 
    stats_month Int 
    stats_year Int 
    stats_time DATETIME

)

То, что я пытаюсь сделать, это рассчитать общий вид с hourly_stats на определенный период времени и группировки записей по file_id, а затем добавить/обновлять записи до таблицы full_stats. На avg требуется 1-2 минуты для обработки одной строки. Я пытаюсь оптимизировать запросы для повышения производительности.

Вот что я делаю

Есть 60% вероятности того, что file_id уже существует в full_stats для данной недели, месяца, года и 40% вероятности того, что он не существует.

так в первом запросе я пытаюсь обновить запись, используя следующий запрос

UPDATE full_stats 
    SET total_views=XXX 
WHERE stats_week=XX stats_month=X 
    AND stats_year=YYYY

после этого я проверяю, если затронутых строк равно нулю, то я вставить запись. После того, как вставка или обновление завершены, запись с hourly_stats удаляется на основе file_id и заданного периода времени.

Можете ли вы дать мне какое-либо предложение по оптимизации запросов и снижению скорости блокировки?

источник

2010-08-13 Maximus

Какую индексацию вы настроили на этой таблице? – FrustratedWithFormsDesigner

Использование SSD, подключенного к RAID-массиву, должно ускорить ввод-вывод. Шутки в сторону? Пока добавляются индексы, он должен работать так быстро, как это возможно. В этом случае любая оптимизация будет мало для производительности. Возможно, вы смотрите на полную редизайн системы, но здесь нет никаких подсказок, потому что, если вы нажимаете одно место, вы теряете в другом, и слишком мало деталей дается, чтобы выяснить, что можно сделать лучше. – AlexanderMP

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

Индекс приводит к низкой производительности, когда индекс должен быть перезаписан или обновлен после каждой вставки/обновления. Это более вероятно с регулярными индексами.
Однако в вашем случае это звучит так, как будто вам нужен уникальный индекс. При этом у вас может не возникнуть эта проблема (так много).

Убедитесь, что ваш стол использует двигатель InnoDB и имеет уникальный индекс на (stats_year, stats_month, stats_week).

Затем, вместо того, чтобы делать обновление сначала, затем проверяя на затронутые строки и вставляя при необходимости, используйте INSERT...ON DUPLICATE KEY UPDATE. Таким образом, в 40% случаев вы позаботились о предыдущем обновлении.
Обратите внимание, что уникальный индекс имеет решающее значение для этого утверждения!

источник

2016-06-01 08:26:16 fancyPants

Оптимизация SQL-запроса для аналитики

ответ

Смежные вопросы