将表做得小一点是有很大利益的。存档或删除数据是保持小表的好方式，但另有其他方式，例如，若是应用是分片架构，则将每个分片做得足够小，从而使得每个表都不会变得很大。也可以将数据分到差别的表中，如对于基于日期的数据，天天都建立一个新表。这里的大多数建议都是对照极端的，并不推荐四处应用，但若是加上一点创造性的话，则可以走得更远一点。
INNODBI的新版本(称为 INNODB插件)，以及tradb，提供在线增添或删除索引的能力，而且速率很快。这一点确实很好。我仍然记得，第一次盘算索引更新需要停机多长时间的情景:客户给了我一个小时，然后运行更新索引的下令，仅仅花了30秒钟，而我记得他们用的是INNODB插件。若是你还没有用过的话，我想INNODB插件版本(或 TRADB)是一次相当引人注目的升级。
若是表不是足够小，则这些类型的操作都是不可能的。这个时刻，就需要另想办法。通过建立一个有着所需结构的ldquo;影子表rdquo;，借助于外部工具，在最后时刻对表举行交流与重命名，虽然理论上可行，我仍然不认为这样做对每种情形都是可行的解决方案。以是，仍然有大量的情形，其中，交流服务器都是首选的方案。
一样平常的想法是设置主一主复制对，固然其中只有一台服务器可写。在只读服务器上执行更新，但不要复制到可写服务器上。可以通过克制将更新写入日志，或在可写服务器上住手复制历程来实现。更新一旦完成，则用正常方式使应用程序实现失效转移，这样，读者和写者就实现了角色变换。然后在另一台网站建设服务器上重复执行更新逐一或许只需要重启复制历程。使用这种方式，就实现了对应用程序隐含宕机时间的目的。
(责任编辑：网络)
评论列表