MySQL «нагон» при импорте строк

Question

У меня есть следующий процесс хрон работает каждый час, чтобы обновить глобальную статистику игры:

• Создать временную таблицу
• Для каждой статистики, вставки строк во временную таблицу (ключ стат , пользователь, оценка, звание)
• Усекать Основные статистика таблицы
• Копирование данных из временной таблицы в главной таблице

л шаг ast вызывает массовое отставание в запросах. Глядя на SHOW PROCESSLIST Я вижу кучу updating -статических запросов, которые застревают до завершения копирования (что может занять до минуты).

Однако я заметил, что он не похож на то, что у него есть последовательные идентификаторы запросов, многие запросы завершаются просто отлично. Так что кажется, что это «нить», которая застряла или что-то в этом роде. Следует также отметить, что застрявшие обновления не имеют ничего общего с текущей копии (различные таблицы и т.д.)

Итак:

• Могу ли я иметь хрон подключиться к MySQL на выделенном «потоке», что его активность диска (или что бы то ни было) не блокирует другие обновления, ИЛИ
• Я неправильно истолковал, что происходит, и если да, то как я могу узнать, что такое реальный случай?

Сообщите мне, если вам нужна дополнительная информация.

Answer 1

Потоки MySQL не имеют полного имени. Например, если вы являетесь разработчиком Java, вы можете сделать некоторые неверные предположения о потоках MySQL на основе ваших знаний Java.

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

SHOW FULL PROCESSLIST 

и попытайтесь понять результат.

В то же время вы можете рассмотреть несколько иной подход к освещению этих часовых характеристик.

1. создать новую, не временную таблицу, называя ее чем-то вроде stats_11 для обновления 11 утра. Если таблица с таким именем уже существует, сначала отбросьте ее.
2. заполнить эту таблицу при необходимости.
3. добавьте необходимые индексы. Иногда заполнение таблицы происходит быстрее, если индексы не на месте, пока вы это делаете.
4. create or replace view stats as select * from stats_11

Следующая час, сделать то же самое с stats_12. Идея состоит в том, чтобы всегда иметь вид stats, указывающий на действительную таблицу статистики.

Это должно сократить время экспозиции до работы с таблицей.

Answer 2

Если задача состоит в том, чтобы полностью восстановить таблицу, это лучше всего:

CREATE TABLE new_stats LIKE stats; 
... fill up new_stats by whatever means ... 
RENAME TABLE stats TO old_stats, new_stats TO stats; 
DROP TABLE old_stats; 

Существует отсутствие помех, так как таблица real всегда доступно и всегда имеет полный набор строк. (OK, RENAME занимает минуточное количество времени.)

Нет ПРОСМОТРОВ, нет ВРЕМЕННОЙ таблицы, без копирования данных, нет необходимости в 24 столах.

Вы можете рассматривать задачу «постоянно», а не ежечасно. Это становится особенно полезным, если таблица становится настолько большой, что почасовая работа cron занимает более одного часа!