基于触发器的弊端：
-
触发器就是存储过程，都是解释型代码，MySQL不会做预编译。把它们硬嵌入到业务操作的事务空间中，会给你要修改的表上执行的每条操作都增加命令分析和解释的开销。
-
锁：触发器与操作语句分享相同的事务空间，当操作语句释放了原始表上的锁之后，触发器再去释放另一张表上的锁。在同步模式下这样行为的后果尤其严重。主库上的锁竞争与写并发有直接关系。我们在生产环境中曾经遇到过锁竞争导致的几乎乃至完全锁住的情况，完全无法访问表或者整个数据库。触发器导致的另一种锁是在创建或销毁触发器时对元数据的锁。在完成修改表定义之后从比较忙的表上删除触发器时，我们曾经碰到几十秒甚至几分钟无法提供服务的情况。
-
无法暂停：当主库业务负载开始增高时，你可能会想要暂停或者取消还没完成的修改表定义的任务。可是基于触发器的方案没办法这么做。也许你可以暂停行拷贝的操作，但却不能暂停触发器，因为把触发器停掉会导致临时表中丢数据。所以，在整个过程中触发器都必须一直处于工作状态。在一些繁忙的服务器上，我们曾经见过即使把在线操作全停掉，最后主库还是被触发器给拖死的情况。
-
并发修改：大家都希望能同时修改多张表的定义。考虑到上面分析的触发器的代价，我们并不敢以触发器的模式同时修改多张表的定义，我们也没听说有哪家公司真的在线上这么干。
-
测试：大家也许想测试一下修改方案是否可行，评估一下负载。基于触发器的方案只能在从库上通过基于语句的复制来模拟一下，由于从库上的复制操作是单线程的（即使用了多线程复制的方案，大部分情况下也还是这样的），这样远不能模拟出在主库上修改过程中的真实情况。
gh-ost
gh-ost是gitHub’s Online Schema Transmogrifier/Transfigurator/Transformer/Thingy的缩写，意思是GitHub的在线表定义转换器。
注意：本文归作者所有，未经作者允许，不得转载
