对于运维来说，对数据库模式进行更新，是许多非常困难的任务之一。将数据库模式与其他更新一起进行同步，有几种常见的情景:部署、快速开发、通过修改索引和其他结构优化性能。假如模式更新是一种阻塞操作(MYSQL中通常就是这样的)，这就真的成问题了。



将表做得小一点是有很大好处的。存档或删除数据是保持小表的好方法，但还有其他方法，例如，假如应用是分片架构，则将每个分片做得足够小，从而使得每个表都不会变得很大。也可以将数据分到不同的表中，如对于基于日期的数据，每天都创建一个新表。这里的大多数建议都是比较极端的，并不推荐到处应用，但假如加上一点创造性的话，则可以走得更远一点。

INNODBI的新版本(称为 INNODB插件)，以及Xtradb，提供在线增加或删除索引的能力，而且速度很快。这一点确实很好。我仍然记得，第一次计算索引更新需要停机多长时间的情景:客户给了我一个小时，然后运行更新索引的命令，仅仅花了30秒钟，而我记得他们用的是INNODB插件。假如你还没有用过的话，我想INNODB插件版本(或 XTRADB)是一次相当引人注目的升级。

如果表不是足够小，则这些类型的操作都是不可能的。这个时候，就需要另想办法。通过创建一个有着所需结构的"影子表"，借助于外部工具，在最后时刻对表进行交换与重命名，虽然理论上可行，我仍然不认为这样做对每种情形都是可行的解决方案。所以，仍然有大量的情况，其中，交换服务器都是首选的方案。

一般的想法是设置主一主复制对，当然其中只有一台服务器可写。在只读服务器上执行更新，但不要复制到可写服务器上。可以通过禁止将更新写入日志，或在可写服务器上停止复制过程来实现。更新一旦完成，则用正常方式使应用程序实现失效转移，这样，读者和写者就实现了角色变换。然后在另一台网站建设服务器上重复执行更新一一或许只需要重启复制过程。使用这种方式，就实现了对应用程序隐含宕机时间的目的。