我很好奇听到人们使用在MySQL中非常大的表上执行修改的策略和方法。 大可能是任何数量的行或大小，将影响改变。 为了交谈，我们假设有200万行以上的任何修改将影响正常的应用程序性能。
我所看到的两个主要策略是：在一个从属设备上执行alter，然后在完成后提升它成为主设备，或者创build一个已经完成预定的更改的表的副本，然后复制并追踪数据，在删除旧的之前做一个重命名交换它们。
我理想的是寻求办法来做后者。 我的一个大问题是在表格上的触发器被改变，并且当然确保两个表格中的数据在被交换之前保持同步。 我认为可以在一定程度上减less错误或丢失数据的可能性，在进程中的关键点使用read_onlyvariables，以确保数据在触发器的摆弄和抓取所有数据后不会发生变化。 我知道这会对使用数据库的应用程序产生影响，但它比冒着损坏的数据风险要好。
我一直在寻找这样做的公用事业和战略，有几个在那里。 其中一个值得注意的就是Facebook，它是在线修改的基础。 ： openark套件文档 。 这个过程在这里详细阐述： 在线模式变化的想法和想法
你对这两种方法有什么经验？ 你遇到了什么陷阱和陷阱？ 你喜欢/build议哪个，为什么？
Percona / Maatkit也有自己的： pt-online-schema-change
我使用触发器方法对超过1亿行的表进行了联机模式更改，并且工作得非常好。
将触发器添加到旧表中以将插入的数据复制到新表中。 它看起来像这样：
DELIMITER | CREATE TRIGGER original_to_new AFTER INSERT ON original_table FOR EACH ROW BEGIN INSERT INTO new_table SET col1 = NEW.col1, col2 = NEW.col2... END; | DELIMITER ; 记下第一个自动递增的ID，用触发器移动到新表中。
RENAME original_table TO original_table_backup, new_table TO original_table Continnt人员在他们的Tungsten Enterprise产品中包含了这种能力。 例如，请参阅： https : //s3.amazonaws.com/releases.continuent.com/doc/tungsten-1.3.3/html/Tungsten-Concepts-And-Administration-Guide/content/ch03s19.html