我有一个访问量很大的表，其中包含用户的私人消息，有超过 1000 万行。当我运行用户删除过程时，过时的消息会从表中删除，通常超过 1000 行。当这个表被优化时，问题就出现了，因为这需要将近 1 分钟的时间，在此期间表被完全锁定并且所有查询都被延迟。其他大型表也是如此。
问题是，我是否可以简单地让表永远不进行优化而不会导致重大的性能问题？或者我应该每周至少优化一次表格，最好是在流量较低的时候，以免惹恼我的在线用户？
答案1
是的，性能会下降 - 但我们无法告诉你下降的速度有多快，或者下降到什么程度是可以接受的 - 因为你已经在这样做了你为什么不自己衡量一下影响。
Akber 说得对，使用集群可以让你优化一个系统，而另一个系统仍提供数据 - 但为什么不将它们设置为主主对 - 那么你在切换时就不需要升级和降级。而且不需要写入临时记录 - 只需等待服务器延迟恢复然后切换即可。对于备份和高可用性来说，这也是一个非常好的解决方案。
另一种已广泛用于此类练习的解决方案是零停机模式更改 - 我知道有两种很好的实现：一种是用Percona 的 Perl 开发者，以及一个用 PHP 编写由 Facebook 人员提供。
答案2
我认为您的意思是重新组织表以删除已删除行所占用的空间。
最简单的解决方案是通过复制：
- 将表或整个数据库复制到另一个 mySQL 服务器或实例（从属）
- 在从属服务器上创建具有只读权限的用户。
- 使用只读用户将应用程序连接切换到从属服务器。当新记录插入失败时显示适当的消息。
- 优化一下master然后切换回来。
可以使用更复杂的变体将临时记录写入从属服务器中的另一个表，然后将其复制回主服务器，但这将涉及应用程序级别的更改。
理想的解决方案是有一个写入队列以及可写和只读表。这种设计模式类似于控制查询规则。它基于最终一致性，您的用户甚至可能不会注意到任何波动。所有写入事务最终都将写入表中，但可能无法立即使用，因为它们在可写表重新组织时被保留在队列中。