巅峰问答 | 从源码到运维，MySQL DBA该何去何从？

巅峰问答 | 从源码到运维，MySQL DBA该何去何从？

编辑

萧田国（整理 & 发布）

主要讨论人员

提问：盖国强@云和恩墨回答：周彦伟@去哪儿

嘉宾介绍

盖国强云和恩墨创始人，Oracle ACE 总监，ITPUB 版主。十余年Oracle 从业经验，中国地区首位Oracle ACE 和ACE 总监，中国地区最著名的Oracle 专家及技术推广者之一。周彦伟ACMUG 联合创始人，去哪儿网数据库总监。十余年的MySQL 从业经验，中国地区最著名的MySQL 专家之一。

引言

「坐而论道」是一个轮流问答的玩法，在回答完提问后，有权向下一位群里朋友提问，以此类推。

本文是数据库主题周中，几位国内一线专家激情问答的一部分内容。期间，各位群友也积极参与。

精彩问题

本文涉及的提问包括如下几个：

用户该选择怎样的MySQL 分支？从源码到运维，MySQL DBA 该何去何从？

以下为周彦伟大师的回复，句句精彩哦。

Q1：用户该选择怎样的MySQL 分支？

盖老师问：随着Oracle 囊括MySQL 而去，用户对于MySQL 命运的担忧从未停止。

然而官方版本的各种特性确实在不断增强，从GTID 到MTS，Oracle 解决了MySQL 的很多历史问题，同时诸如MariaDB等新的分支又激活了开源的引擎。

Oracle 官方分支与其他分支相比，是否具备明确的更新优势，用户该怎样去进行选择？进一步的，周总认为MySQL 最吸引用户的地方是什么，比如和Oracle数据库对比（不谈成本）？

如下为周彦伟的精彩回答。

MySQL 的版本，个人认为比较靠谱的有三：MySQL 官方版本，Percona 版本，MariaDB 版本。

MySQL 官方版本

MySQL 官方版本当然是正统，不管是代码开发人员，还是各种测试，文档，社区维护都是最强大，最全面的。我估计也是目前使用量最大的版本。它对bug 的修改和功能性代码补丁的merge 都很专业，谨慎，可靠性比较高。

它的缺点，庞大的机构和冗长的流程，会导致代码更新缓慢，一些热点功能不能很快的反应到官方GA 版本上，如果希望用到比较实用的社区开发人员提供的补丁，可能需要等待很长时间。

MySQL 官方在企业版和社区版之间徘徊，感觉他们还没想好到底怎么发展MySQL。很好的工具不能免费提供给使用者，又想要走收费的道路。然后，又等着开源社区来革命。

MariaDB

反之，MariaDB 在这方面比较接地气，很多最新的功能都能快速的加入和实现，很多人选择它就是因为这点。

Monty（作者）本人感觉比较激进，比较从谏如流。

但是MariaDB还是太年轻，各个环节还不够成熟，专职的开发者也少。并且很重要的是，很可能上了道之后就回不来了。慢慢的会偏离MySQL。

Percona版本

Percona版本是官方版的超集。

它在官方版本的基础之上又加入了很多补丁，同时Percona 已经修成一个基于MySQL 的生态圈了，各种工具，方案，文档都很齐全。对MySQL 用户来说是一个不错的选择。

但是令人堪忧的事情是，Percona 自身的开发能力，特别是对InnoDB 的开发和修改能力慢慢趋于弱势：

真正有实力的人，应该还在官方。

不过，鉴于Percona 完全兼容官方版本，我目前还是选择了它。

我认为自由是开源数据库的兴起之源，特别是在互联网行业，自由之风盛行，所以开源数据库可以大行其道。

作为使用者来说，知其然并知其所以然的状态是最好。

并且，在开源面前不仅仅如此，知其所以然、而后对其拆骨动筋，使之为我所用，听我所嘱，这也只有开源可以办得到。

另外，开源社区的氛围，也是大家学习和进步之源，不仅能直接吸收其编码的精华，也可以借鉴他人之经验，整体欣欣向荣，互相促进，共同进步，如此蓝图，岂不乐乎。

Q2：从源码到运维，MySQL的DBA何去何从？

盖老师问：有人说玩开源产品就要玩源码，MySQL DBA 中有一类独特的群体是代码开发者，和Oracle DBA 比较起来，单纯的MySQL 的运维似乎可以腾挪的空间更小。

作为MySQL DBA，应该如何选择MySQL 入行的方向，不同方向的关系又是如何的？

我也非常想知道周总在MySQL 的职业生涯中，是从哪个角度入行，对于源码的认识是怎样的，从人人网到去哪儿，角色和技术上又有哪些转变？

如下为周彦伟的精彩回答。

我个人是抱着读源码的信心入行做运维DBA的。在改行做DBA 之前，我已经做开发超过5年有余。

陡然换一个新的职业的信心来自于自己编程的经验，当时要决定做DBA 时，我对自己说了一句话：

MySQL不就是一个程序么，代码都在那里，还有啥搞不定的？

但造化弄人，我并没有对源码有过很多深入的研究，甚至没有通读过一遍。在当时的工作，研发和DBA 比例超过200：1。工作压力巨大，早期的MySQL 知识恰恰都是从运维中获得的。

从这点可以说，运维也可以干得很不错。我也相信，到目前为止还是有很多人没有看过源码，但在DBA 的岗位上非常优秀和成功的。

同时，我也注意到，很多从源码起步的人，并不一定能把运维这个事儿搞得很好，甚至会一团糟，各种理论的书面经验并不能有效转化为生产力，有时候甚至会捅大娄子。

认真总结可以发现，源码和运维是两种完全不同的思维模式和做事方式：

相对而言，源码需要的是更为抽象的算法，编程能力，思维能力，而运维更侧重于经验的总结，行为的准则，人性的展示，运维往往更能反映人性。

我之前在人人上发状态有过这样的表达：DBA是一种生活方式。DBA是一种态度。

我个人比较幸运的是，在经历了大规模，高强度，超负荷的运维DBA 的过程中，不断接触到了数据库源码和研究数据库源码的人，他们给我纠正了很多我在运维过程中猜到的一些经验，这些经验在源码面前被揭露的一览无余，让我改变看法，积累正确的知识，不断进步。

在此，我要谢谢这些好朋友，竹峰，立勋，丁奇，古雷，利兵，登博，禇霸等等。当然，获取数据库的知识也来自从运维入手的一批朋友，诸如炳锡，金荣，启荣，发明，李凌，应钢等等，这些都是良师益友。

关于源码和运维，我的周围还有这样的奇才，从源码转而运维，从运维转而源码。

总而言之，二者如果能很好的结合起来，在运维过程中参照源码来指导工作，把运维的需求变成源码沉淀，这才是MySQL DBA 最好的工作方式，这些人的成就，我已经望尘莫及了（周董太谦虚了啊…编著注）。

MySQL DBA 或者DBA 的发展，除了更深入的钻研源码以达到MySQL 界“扫地僧”的造诣之外，可发展的空间还有两条路：

对底层架构的把握和设计。MySQL 是需要架构的，而且需要功力很深的设计，不管是扩展性还是可用性，它自身都没有很好得解决方案。这需要从上层角度，根据自己业务的需求和特点，选择不能的架构思路，甚至在一个公司内部，根据公司的业务不同，也需要选择不同的方案，物尽其用，物有所值才是持家之道。对业务逻辑和架构的深入。我记得这是在跟童家旺大师聊天时候他提到的一个观点，我对此非常认同。数据库跟业务再也不是路人甲乙的身份了：数据库的优化需要了解业务的真实需求和特点，业务技术架构和方案的设定也需要深入了解数据库的特点，把二者结合起来考虑，各自扬长避短，才能和谐工作，提升效率。DBA 就是这其中的桥梁，DBA 要上得厅堂，下得厨房，做到深入了解每一个分表，每个SQL 的真正意义，才能更好得去优化和设计。这样的DBA 才是有价值的DBA，才是业务和企业最离不开的人，这其中的空间无比的宽广，非常非常值得探究。

目前来看，MySQL DBA 在逐渐往这些路上前行，但是Oracle 方面，由于传统的习惯和Oracle 数据库大包大揽的特点，反而数据库和业务离得比较远一些。

目前的Oracle DBA 没有MySQL DBA 那么抢手，这是不是也是一个原因？

我个人从之前的人人网到去哪儿网之后，担任了数据库总监的职务，在短期内把DBA 团队发展壮大到超过原来的3倍，同时扩大了DBA 的业务，从原来狭义的DBA 只顾MySQL 这一项内容扩展到MySQL，HBase，Redis，甚至SQL Server。

这其中有公司的需求，也有个人以及团队发展的考虑。在MySQLR上的主要工作是作为架构师的角色，带领和伙同兄弟们一起做了不少底层的革新：

从制定MySQL 开发规范，到架构PXC，从开拓RedisR业务到目前的HBase 的初见成效，从带动公司硬件的革命，到推出开源审核产品InceptionSQL，也算做了一些事情。

如何一起愉快地发展

提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请；或申请加入我们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。

题图来自：http://photofans.cn/