对于运维来说，对数据库模式进行更新，是很多异常艰苦的义务之一。将数据库模式与其他更新一路进行同步，有几种常见的情景:安排、快速开辟、经由过程修正索引和其他构造优化机能。假如模式更新是一种壅塞操作(MYSQL中平日就是如许的)，这就真的成问题了。

将表做得小一点是有很年夜利益的。存档或删除数据是坚持小表的好办法，但还有其他办法，例如，假如运用是分片架构，则将每个分片做得足够小，从而使得每个表都不会变得很年夜。也可以将数据分到分歧的表中，如对于基于日期的数据，天天都创立一个新表。这里的年夜多半建议都是比拟极端的，并不推举随处运用，但假如加上一点发明性的话，则可以走得更远一点。

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

假如表不是足够小，则这些类型的操作都是弗成能的。这个时刻，就须要另想方法。经由过程创立一个有着所需构造的“影子表”，借助于外部对象，在最后时刻对表进行交流与重定名，固然理论上可行，我仍然不以为如许做对每种情况都是可行的解决计划。所以，仍然有年夜量的情形，个中，交流办事器都是首选的计划。

一般的设法主意是设置主一主复制对，当然个中只有一台办事器可写。在只读办事器上履行更新，但不要复制到可写办事器上。可以经由过程制止将更新写入日记，或在可写办事器上停滞复制进程来实现。更新一旦完成，则用正常方法使运用法式实现掉效转移，如许，读者和写者就实现了脚色变换。然后在另一台网站扶植办事器上反复履行更新一一或许只须要重启复制进程。应用这种方法，就实现了对运用法式隐含宕机时光的目标。