记一次读写分离的数据库表加字段的连锁反应

   事情是这样，数据库中有张数据量近亿级的表，由于业务原因要加1个字段，由于没有专门的DBA就有我亲自上场。。。
   一般这种事情，常规是放到晚上业务量小的时候进行，这次不知道搭错了哪根筋，想着读写分离，主库的日常压力非常低，异想天开的就开始加字段，想着观察监控，即便是CPU，内存上去了，也有足够的时间终止，不影响正常业务。
   看似一切顺利的就开始作死操作，从2点开始，一直持续到4点45分，字段终于加完了，期间CPU占用率从日常的1～3%升到了10%左右，本来觉得问题不大，只是时间问题。可万万没想到的是这只是主库完成字段添加，主库完成后从库才开始加字段，这时候从库的同步延迟直线上升，阿里云的读写分离一旦有延迟，会把所有读操作都指向回到主库，这时候主库的读写压力瞬间爬升。CPU占用率也上升到了40%左右，当时观察到主库多了很多查询语句和CPU升高，脑子嗡嗡的，如果主库的性能不足到支撑全量读写SQL，那么业务系统就要崩了，而且就算这时候再删字段也来不及操作了。。。。
   这里总结了一个教训，有大表的时候能早点分表早点分，如果亿级的表要加字段一定要慎之又慎，尤其是还挂着读写分离，一个不小心就有可能会有连锁反应。