偶然看到  去哪网  大佬转发的一篇文字，倍感亲切，想起和MYSQL 的那些年的青葱时光， 那些年去哪网的MYSQL技术一直是很多MYSQL DBA 的指路明灯，尤其是MYSQL 当时“时髦”的PXC 技术都是要看去哪网的“指引”。遥想当时的确是10几年前的事情了。

后面去哪网又做了业内开源的 Inception ，轰动一时。大厂小厂都纷纷使用效仿，或修改源代码。

当时的MYSQL 使用的版本大部分都在5.6 （还有部分在5.5），问题是一大堆，各种的高可用方式也是都在试着用，没有现在那么多的可参考的文字或各种MYSQL的大佬，去哪网那时在业内用了percona 的 xtradb cluster， 基于galera ，我们使用也踩了不少坑，进行DDL 操作时虽然使用了PT-OSC，部分情况也有导致整体集群 hang 住的情况，也有因为其他原因集群解体的情况等等，现在想想这都与当时不理解高可用成型的模式和原理有关。

为什么要写这篇文字，主要是在读完王老师写的这篇文字里面有很多的想法被证明，至少不是一个人这样想。

主要有以下几点：

1  需求与实现

目前市面上有不少的数据库产品，从数据库本身到运维产品等等部分产品本身并未从使用者的角度出发，而是站在自己（开发者）的角度来臆想客户的需求。产生的产品本身看上去什么功能都有，但都不大好用，或使用起来老是觉得缺点什么。这就是需求和实现分割了，并未达成一致，尤其在当前的商业环境，产品能力可以在品鉴会或宣传上称之为 “十全大补”，在使用中却给使用者一些不良的感受，最终感觉受到了欺骗。另外也反映出另一个事实，目前数据库产品，或者说搞数据库产品的人，部分是业外人士，搞完的产品也是业外产物。

2  DBA 要不要会写程序的问题，答案是一定要，必须要。

文中也提到，需求方DBA本身如果不会程序，或不具备程序能力，则只能受制于人，并且那些写代码的，也未必懂得你的需求，沟通成本高。最终可能产品方对产品本身也就妥协了。另外云产品的步步紧逼，纯运维的道路的确是好走不了，不给自己绑定一个其他的能力或身份，那就比较孤单了。

3  思维的灵活性 与 学会利用资源

人是地球上同种类具有最大不同点的生物，动物出生前，出生后大多是“公平”的， 人不是，有人出生时已经是其他人结束前想追求的样子，既然不同人的间隔这么大，那就的学会利用资源，学习可以不光是技术，如业务能力，理解能力，以及辨析能力，甚至是 厚脸皮 都是能力，都能提高自己的存活层次。

4 新技术的问题

这点说出了不少，为了更新而更新的  “白” 们。如数据库上docker这件事，很多单位都还没有把单体数据库的问题解决，本身自己管理数据库的能力有问题，造成各种故障，此时想跨越，或者赶时髦，立马上一些听上去高大上的技术，但实际上自己连现在的技术都没有掌握，妄想搞新技术就能摆脱现在的窘境，并且新技术的运用也是需要老的知识的积累和积淀，没有弄清楚自己目前到底是什么问题，为脸上贴金的上分布式，上DOCKER，并且根本不考虑企业成本的行为，可以称之为  盲， 盲从的盲，说明自己没有什么辨别和识别的能力，即使上了新技术，一锅粥继续熬，砸锅的可能性那是相当的高。

5 产品化的思维

工作了不少年了，产品化的思维是可以运用到DB 的工作中，首先自己就是一个产品，一个市场上被雇主雇佣的产品，（说的冷冰冰，其实就是冷冰冰），别不把自己当人看，也别太把自己当人看，在雇主面前，你就是一个产品，一个成本低，效益高的产品 （他希望的）。

自己的工作以及工作成果也是产品，如果数据库管理工作一直是纯手工，几十年如一日的重复性工作看，自己的工作成果是不是成本高，效率低的代名词，不优化你优化谁。

另自己在工作中，可以产出一些产品，利用自己的时间成本，看看能不能产出一些带有自己标签的产品，产品可以是多种多样的，可以是知识的分享，或者解决工作中的难题，或是写一些工具，放到GITHUB上等等。 把自己当做一个产品去维护，让自己这个产品能在市场上多活几年。

6  心底多问为什么

规则存在一个地方自然有原因，而这些原因是否是合适的，合理的，新到一个地方，大部分人都会提出各种各样的问题，而时间长了，很多不合理的东西也变得合理，并且自己也不在思考，默默接受。 规则也有不适合的地方（确实是有不合适的），凭自己的能力，能改变，哪怕是一点，让自己不麻木，那还能证明自己的价值和存活的意义。

最后，对于文中提到的 MYSQL 全日志分析，智能报警和慢SQL 风险指数等等都是好东西，的学习先进思想了。

从王老师的文中，最大的体会就是量变产生质变，10多年的工作经验，的确不是“一个经验”。