MySQL ALTER TABLE ORDER BY f1 DESC - 这是否阻止SELECT查询？

Question

我有一个由2个unsigned int字段组成的MySQL MYISAM表（称为tbl），比如f1和f2。在f2上有一个索引，表格非常大（大约320,000,000+行）。我定期更新此表（每周大约有100,000个新行），为了能够在不执行ORDER BY（这在实时查询中非常耗时）的情况下搜索此表，我实际对表进行了ORDER根据我想要检索其行的方式。

因此，我执行一个ALTER TABLE tbl ORDER BY f1 DESC。 （我知道我在服务器上有足够的物理空间来存放表的副本）。我已经读过，在此操作期间，创建了一个临时表，并且SELECT语句在当前行上不受影响。

但是，我经历过，情况并非如此，并且在与ALTER表同时发生的表上的SELECT语句被阻止并且不终止。 ALTER TABLE tbl完成后（生产服务器上大约40分钟），tbl上的SELECT语句再次开始执行正常。

是否有任何理由为什么“ALTER表tbl ORDER BY f1 DESC”似乎阻止其他客户端查询tbl？

Answer 1

更改一个表总是会在表上锁定一个锁，从而阻止SELECT运行。

我将管理员，我甚至不知道你可以用ALTER TABLE做到这一点。

你想从桌子上得到什么？例如，给定范围内的所有记录？ 3.2亿行不是一个微不足道的数字。我给你我的直觉反应：

1. 切换到InnoDB的（允许＃2，也给了交易，但没有＃2可能会损害性能）
2. 分区表（使它像一些轻微小表）
3. 考虑重新设计，如具有“工作集”表和“历史”表，基本上手动分区。如果你通常寻找最近插入的数据，这（与分区一起）会有很大的帮助。如果你的查询是均匀分布的，这可能不会有什么区别。
4. 考虑加入，你可以结合使用，以缩小选择新的一列（所以不是在日期检索，日期和客户ID搜索）

因为我不知道你要存储什么，其中一些（如＃4）可能不适用。

还有一些其他的事情可以尝试。 OPTIMIZE TABLE可能会帮助你，但花费更少的时间，但我怀疑它。我认为它在内部是作为dump/reload实现的，至少在InnoDB方面。