Question

我每小时运行以下cron进程来更新全局游戏统计信息：

创建临时表
对于每个统计信息，请将行插入临时表（统计密钥，用户，分数，排名）
截断主要统计表
将数据从临时表复制到主表

最后一步导致查询大量积压。查看SHOW PROCESSLIST我看到一堆updating - 状态查询一直停留，直到复制完成（可能需要一分钟）。

但是我确实注意到它不像是连续的查询ID堆积起来，很多查询都很好。因此，它似乎是一个“线程”被卡住或什么的。另外值得注意的是，卡住的更新与正在进行的副本（不同的表格等）没有任何共同之处

所以：

我可以让cron在专用“线程”上连接到MySQL，这样它的磁盘活动（或其他任何东西）都不会锁定其他更新，或者
我是否误解了正在发生的事情，如果是这样，我怎样才能知道实际情况是什么？

如果您需要更多信息，请与我们联系。

Answer 1

MySQL线程没有完美命名。例如，如果您是Java开发人员，则可能会根据您的Java知识对MySQL线程做出一些不真实的假设。

由于某些原因，远距离诊断很难，您的复制步骤会阻止某些查询完成。如果您对哪些人尝试做什么感到好奇

 SHOW FULL PROCESSLIST

并尝试理解结果。

与此同时，您可能会考虑采用略微不同的方法来刷新这些每小时的统计数据。

创建一个新的非临时表，在11am更新时将其称为stats_11。如果已存在具有该名称的表，请先删除旧表。
根据需要填充该表。
添加所需的索引。如果在您执行索引时，有时填充表格会更快。
create or replace view stats as select * from stats_11

下一个小时，对stats_12执行相同的操作。我们的想法是让您的stats视图几乎始终指向有效的统计信息表。

这可以减少你在stats-table building operaiton的曝光时间。

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始终可用且始终具有完整的行集。（好的，RENAME确实需要花费很少的时间。）

没有VIEW，没有TEMPORARY表，没有复制数据，不需要24个表。

你可以考虑“不断”地完成任务，而不是每小时。如果表格变得如此之大以至于每小时的cron作业需要超过一个小时，这就变得特别有用了！

导入行时MySQL“堆积”

2 个答案: