DBA解题集：也谈闭环时

我认为工作的核心就是闭环，如果想做优秀员工，必须完成闭环。

在过去的一年里，我慢慢学会了团队的一个习惯，那便是，这件事情的闭环标准是什么？也许，老板有老板的标准，但不管何时，在交付前他通常不知道自己想要什么，除非你给他需要的东西。从这个角度讲，不管遇到什么事情，都应该扪心自问：“怎样才算做好？”，如果能把任务分而治之，那么确定“做好”的标准或许清晰些，因为每个子任务的闭环标准可能已经自然存在，起码有这么一条：“如果这个做不好，那么下一个就没法开始……”

那么，什么是闭环？我举个例子：2015-12-25日协同开发参与优化QT语音下属的掌盟俱乐部话题业务计数，在优化前业务侧是通过SQL实现俱乐部话题业务数的统计，方式如下：

yw@Tencent64[db_circle]mysql> select count(1) from t_circle_topic_74 force index(idx_app_circle_id) where app_id=1 and circle_id='13';
+----------+
| count(1) |
+----------+
|  1403174 |
+----------+
1 row in set (4.11 sec)

这种方式响应时间为4秒，较搓，产品不能忍。优化手段是通过新建一张计数表 t_circle_topic_total ，含app_id，circle_id，每隔一段时间更新该表 replace 下该汇总表，查询直接走该表，这样几百微妙就出结果：

ADMIN@Tencent64[db_circle]mysql> select tatal from t_circle_topic_total where app_id=1 and circle_id='41';
+-------+
| tatal |
+-------+
| 14241 |
+-------+
1 row in set (0.00 sec) --> 365微妙

这就是一个DBA日常的业务支撑，其实很平常，没啥亮点。

可你花费了小半天时间做的事情就这样草草收尾？至少得知道它对项目的收益如何？能有数据可以量化。于是，也就是在2015年12月28日，我找了开发要了优化后的数据，其中单个用户查询时间由 4000 毫秒 下降到 0.3 毫秒，大大改善了用户体验，从体验数据改善就能很直观地反馈本次极为普通的优化手段所带来的效益。这样你在向老板汇报的时候也有牛逼可以吹，你说，系不系啊？！

通过对本次支撑工作的收尾，这就是一个闭环的例子。

对于基于工作的逻辑思考乐趣有兴趣？扫扫我的二维码，咱聊聊吧