口水记

又过了一个周末，早晨自然又是踩点。请叫我踩点小猿。

上午都在忙着优化那日增几百万的数据库表了。

通过一些会议讨论，还是需要改动表结构才能进行分库分表，否则无法进行下去。因为通过什么字段的查询语句都有，那么这怎么分嘛~分了之后，未命中分表字段的查询那岂不是更坑。

所以新增了一个字段，该字段在所有的查询中，理论上都需要用到的，可惜的是，之前数据库的设计，未存储该字段。

现在要做的就是如下几步。（必须要做，不做的话，过些天就有宕机危险）

• 梳理出所有的查询sql
• 增加新字段作为查询条件
• 修改dao层的原有所有接口，增加参数
• 内部接口梳理出来，单独进行优化
• 对于原有API接口，新增接口，原有接口第一版本不做改动，做删除标识
• 通过调用关系，找到所有相关对外暴露的API接口
• 通过zk找到所有的消费者应用
• 找到相关应用负责人，通知升级版本，以及告知原接口废弃时间点
• 在废弃时间点后，项目版本会再升级，对于标识删除的接口实现，直接进行抛异常处理
• 所有插入语句的接口，增加新增字段的值的插入
• 旧数据订正脚本准备

以上就是填坑的全部步骤，其中测试无法覆盖的风险、遗漏应用或者相关负责人未及时更改的风险极有可能会发生。

做到项目逻辑不变动，上游应用通知到位。及时通知，及时跟进。

由于改动的结构比较底层，改动的地方与接口非常多，涉及接口几十个，相关上游项目也有几十个，要通知的人更不用说了。

相对来说，这是一个风险比较大的改动，但是又不得不做的事情。只能是谨慎再谨慎了。

下午倒是开了一个3小时的需求评审，由于我这边还有比较紧急的优化，我只是过去旁听并提提意见，毕竟，多熟悉熟悉团队其他项目，其他需求是非常必要的。

晚上抽空去健身了，游泳撸铁，一天的生活就这么过去。

小结

今天还是比较充实的一天。

需求评审的时间还是太久了，强烈建议所有产品，超过2小时的需求，都拆成两个需求来做，小步快跑。

优先做比较重要的部分功能。

不正经语录

• 3个小时的会议，能认真听进去的并互动的，也就是前半场，后半场人都迷糊了
• 产品说的需求不会变动，记得录音，下次改需求，记得放录音，拿二维码

声明

本文故事纯属遐想，如有雷同，我是原创。

欢迎转载。
转载请务必注明以下信息。
原作者：谙忆
原文地址：https://copyfuture.com/blogs-details/20200518225101652gn1tq0mbp8pulc9

公众号

更多精彩内容、活动、程序猿的小故事，欢迎扫码关注公众号