关于SQL自动化上线，之前码了一篇简单的实现，发现大家对这块的关注还是比较多，通过一些反馈了解，感觉整体大家现在的SQL上线状态离自动化还有距离。
当然要实现这样一个步骤，肯定有很多前置的工作要做，我觉得可以把他统称为一类运维角色，前置运维。
create的操作整理了一版，整体从运行情况来说，是完全可控，当然在体验上再优化一些之后，发现我们的业务需求可以更快的响应，同时我们也可以更加关注于数据库内部技术的工作。这种解放势必会给我们带来不小的幸福度，目前来看，现在的成就感大于幸福度，而且还是在试运行。
在这个基础上，根据目前收集的变更需求，除了drop,truncate本身不支持以外，就只有create和alter操作了。alter操作本身是带有一些敏感性的，主要还是取决于数据量和结构。从目前接受的需求来看，大部分的需求其实表数据量也不大，基本不到20000条，变更时间都在毫秒级别。
所以我们取普遍需求而言，对于大部分的需求其实是应该支持的。其实加个字段，表数据量不大，为什么不自动化呢，我设计了如下的步骤：
其实变更的难点在于如何去评估表的数据量，这里我是采用完全离线的方式，我这边会去定期采集表的信息，比如碎片情况，数据量等，我们完全可以通过离线数据拿到这些数据，如果数据量不大，那么这个工作的性价比就很高了。
在确认可行后，直接在后端生成异步任务来对接，简直是酸爽。
如果数据量大，我们可以使用pt工具来对接，保证备份即可。
