我有一个带有 400 万行的 MyISAM 表的 MySQL 数据库。我大约每周用大约 2000 行更新这个表。更新后，我然后像这样更改表：
ALTER TABLE x ORDER BY PK DESC
我按主键字段降序对表进行排序。这在我的开发机器（具有 3GB 内存的 Windows）上没有给我任何问题。我已经在生产 Linux 服务器上成功尝试了 3 次（使用 512MB 内存 - 每次大约 6 分钟即可获得结果排序表），最后一次尝试时我不得不在大约 30 分钟后停止查询并重建来自备份的数据库。
一个 512MB 的服务器能应付这么大的表上的 alter 语句吗？我读过创建了一个临时表来执行 ALTER TABLE 命令。
问：这个alter命令可以安全运行吗？更改表格的预期时间应该是多少？
正如我刚刚读到的，该ALTER TABLE ... ORDER BY ...查询对于在某些情况下提高性能很有用。我很惊讶 PK 指数对此没有帮助。但是，从MySQL docs看来，InnoDB确实使用了索引。然而，InnoDB 往往比 MyISAM 慢。也就是说，使用 InnoDB，您不需要重新排序表，但您会失去 MyISAM 的超快速度。它仍然值得一试。
您解释问题的方式，似乎有太多数据加载到内存中（甚至可能正在进行交换？）。您可以通过监控内存使用情况轻松检查。很难说，因为我不太了解 MySQL。
另一方面，我认为您的问题出在一个非常不同的地方：您正在使用只有 512 Megs RAM 的机器作为数据库服务器，其中的表包含超过 4Mio 行......而且您正在执行一个非常占用内存的任务在那台机器上对整个桌子进行操作。似乎 512Megs 还远远不够。
我在这里看到的一个更基本的问题：您正在与生产环境非常不同的环境中进行开发（并且很可能也进行测试）。您正在解释的那种问题是可以预料的。您的开发机器的内存是生产机器的六倍。我相信我可以肯定地说，处理器也快得多。在这种情况下，我建议您创建一个模拟您的生产站点的虚拟机。这样您就可以轻松地测试您的项目，而不会中断生产站点。
是主键 auto_increment 吗？如果是这样，那么执行 ALTER TABLE ... ORDER BY 不会有任何改进，因为无论如何都会按顺序插入所有内容。
（除非你有很多删除）
您要求它做的是重建整个表及其所有索引；这是一项昂贵的操作，特别是如果数据不适合 ram。它会完成，但如果数据不适合内存，它会非常慢，特别是如果你有很多索引。
我质疑您在选择生产中有如此微小的机器时，我质疑您的判断。反正：
您可能还可以进行一些调整以提供帮助；它在很大程度上取决于您的架构（特别是索引）。4M 行不是很多（对于具有正常数量的 ram 的机器）。
如果您使用 InnoDB，则不必显式执行ORDER BY插入后或查询时。根据 MySQL 5.0 手册，InnoDB 已经默认为查询结果的主键排序：
http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480
MyISAM 表默认按插入顺序返回记录，相反，如果您只追加到表而不是使用UPDATE查询来修改任何行，这可能也可以正常工作。
我可能会创建一个按 PK 值排序的视图，因此一方面您不需要在执行 ALTER 时锁定那个巨大的表。