我把上面第三步到第五步高亮出来，这是锁表可能引起系统停机的时间。但步骤六设计外键更新是一个循环的操作，是避免在更新关系的时候隐含地重建表。有很多方法可以确保表的完整性约束，在pt-osc的说明文档中详细说明了，在开始之前预览你的表结构包括约束，并知道怎样把修改表定义所造成的影响降到最低。
最近，我们通知了一个拥有高并发高事务量系统的用户运行pt-osc在大型数据表上。这件事对于他们来说很平常，几小时后我们的客服被告知该客户遇到了最大连接数超过的问题。这个问题是如何产生的呢？当pt-osc运行到步骤五的时候会尝试去锁定数据并重命名原表和隐藏表，然而这不会在开启事务的时候立即执行，因此这条线程会被排在重命名后面。这表现在用户应用上就是系统停机。数据库无法开启新的连接并且所有的线程都被阻塞在重命名命令之后。
5.5.3版本的说明，当开启一个事务时会锁定它会用到的所有表的数据（不依赖于存储引擎），并在事务提交的时候释放锁。这样做确保了在开启事务期间不能修改表的定义。
长远来看我们可以采用一些新的技术来避免这种情况，例如non-default pt-osc的选项，换言之就是不会删除原表把数据换到新表。这种联合脱离了隐藏表和触发器，我们应该鼓励将重命名操作变得原子化。
校订：2.2版本的percona工具新增了一个变量–tries 和变量–set-vars 共同被部署，解决了各种pt-osc操作可能会锁表的情况。pt-osc (–set-vars)默认会设置如下的会话变量当连接到数据库服务器的时候。
当使用 –tries 我们可以颗粒化地鉴别操作，尝试次数、在尝试的间隔等待。这种组合可以确保pt-osc在合适的时机杀掉自己的等待会话进程，确保线程堆栈的空闲，并提供给我们循环操作来获取管理因触发器、重命名、修改外键而造成的锁。
说明文档在这里http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html#cmdoption-pt-online-schema-change–tries
它阐述了即便使用了诸如pt-osc之类的工具，充分了解你想解决的问题是很重要。下面的流程图会帮助你当你了解修改了MYSQL数据库的结构的注意事项。请仔细阅读建议尽管有些图上未标出，例如磁盘空间，IO加载等。
