来源:http://insidemysql.blog.163.com/blog/static/20283404220139145852443/
这几年在做MySQL DBA绩效和面试时会发现一个有趣的现象，考评人或者面试者总会说读过或者正在尝试阅读MySQL数据库的源码。我想我可能是国内最早开始尝试研究MySQL数据库源码的人，并且在我的书籍《MySQL技术内幕：InnoDB存储引擎》中也涉及了一些对于数据库内核实现的源码分析。或许这对MySQL数据库的相关从业者，特别是DBA，产生了一些幻像，认为MySQL DBA一定要阅读源码，从而才能给自己在职场上添砖加瓦。通过我和一些互联网公司的接触来看，各大公司对于MySQL内核开发人员的趋之若鹜，数据库内核的开发人员薪资远高于普通程序员，相信这也提升了数据库内核研究的热潮。但现在，我想就这个问题谈谈自己或许不成熟的看法。
根据传统对于DBA的分类，可以分为运维DBA和产品DBA。运维DBA最为首要的任务就是负责数据库的运维工作，保证MySQL数据库运行的可靠性。产品DBA是对于每个产品或者项目分配的数据库开发人员。其主要用于产品数据库的开发工作，包括表结构的设计、SQL语句和存储过程的审核等等。但是，并不是每个公司的分类都会这么清晰，有些可能根本不存在产品DBA这样的职位，应用的开发人员就负责数据库的开发，而这往往导致了低效SQL语句的本质原因——开发人员仅仅把数据库当成一个简单的存储而已。在在更小规模的公司中，也可能根本不存在运维DBA，SA就是DBA。对于SA来说，MySQL和Apache、Nginx也没有任何区别，根据配置文件启动，遇到问题查看对应日志，然后交付开发方即可。
然而，在强调DevOps的今天，有些公司并不遵循上述运维与产品DBA的数据库人员规划。例如Facebook公司，在其2009年透露的一份数据库报告中可以发现，当时Facebook有1800台MySQL服务器，3000多个数据库实例。但是仅有2个DBA。我想这么少的DBA建立的基础一定是开发人员本身对数据库开发或者运维本身就非常熟悉。
但不管怎么说，对于每个类型的MySQL DBA来说，其能做的事情都非常多。运维DBA不仅是简单的保障数据库的可靠性，同时还需要涉及到MySQL数据库的高可用结构设计、灾备设计、性能监控与调优、容量规划等具体工作。产品DBA还需要了解开发语言、架构、框架等知识。比如Java、Memcached等。因此，在每个细分的领域都能有一大堆事情需要去完成，或者说可以去完成。最简单的问题，有多少个MySQL DBA完整的阅读过MySQL数据库的官方手册？每个新版本发布，又有没有去看过新的章节或者参数的变化呢？
接着从职业规划与发展来看，运维DBA可以朝着运维总监相关的路线发展，开发DBA可以朝着数据库架构师的方向努力，又或者兼而有之。那么请问为什么现在这么多MySQL DBA痴迷于源码研究呢？之前冯大辉在其博客中也做过一些分析与说明，我个人做了些总结和归纳，仅表个人意见，不希望引起过于无聊的争论：
? MySQL数据库官方文档不够详尽
? 阅读一点源码能更了解内部的实现
? 了解源码能在”江湖“上占有优势
我必须要说，MySQL数据库官方文档相对Oracle数据库而言还有一些距离。Oracle官方文档其对数据库的使用进行了分类，如Oracle Administrator’s Guide、Performance Tuning Guide、Concept等。而MySQL数据库将所有说明放在了单独一个文件中，现在MySQL 5.6的官方首次已经接近4700页。分类不清是一个首要问题。其次，MySQL数据库独有的存储引擎也使得文档内容不够包罗万象，给人的感觉都是点到为止。例如对于最为重要、同时也是使用最为广泛的InnoDB存储引擎而言，即使在MySQL 5.6的文档中也仅有不到200页的说明，试问DBA怎么能够了解一些更为内部的实现呢？如redo log、undo log、purge、insert buffer等问题的说明都显得过于简单。反观Oracle数据库有着完善的文档机制，还有Metalink这样的网站提供详尽的问题反馈。此外，在出版市场上，Oracle书籍可谓琳琅满目，又有像Thomas Kyte和盖国强这样的资深业内专家作为作者，相信由此定能解决很多读者在使用遇到的各种疑难杂症。而例如Jonathan Lewis这样的作者又能从Oracle数据库内部的实现来对内部实现进行分析，从而使得相关人员能够更好的理解Oracle数据库的运行机制。虽然InnoDB存储引擎官方博客近期开始具体介绍一些模块的内部实现，但是个人觉得官方还是需要在文档这一方面加强完善。MySQL数据库已经隶属于Oracle公司，因此我们应该完全信任Oracle公司能够做到更好。《MySQL技术内幕：InnoDB存储引擎》一书对InnoDB存储引擎的内核实现做了一些简单的分析，希望国内能有更多的MySQL数据库专家加入到书籍出版与发行的行列中，不但能完成自己的技术积累与分享，同时能帮助更多的MySQL数据库从业人员。
正如前面所说的那样，由于官方文档不够详实，因此有些功能需要通过阅读源码才能了解其本质。比如InnoDB存储引擎的master thread非常重要，但是在文档中确仅一笔带过。insert buffer、adaptive hash index很神奇，但是可能作为DBA希望还能更为了解内部的实现，从而更好地使用。因为，并不是任何时候这些特性都是有用的。不过阅读过源码不代表你真正了解最为本质的实现，这是我最近几年最为深刻的体会。不是有高人指点，相信我现在依然还是盲目地对于数据库内核进行所谓的研究与开发。举例来说，我看过很多人都看过insert buffer模块源码并对其进行了所谓的分析，但是latch的层次设计却从没有人提及过，而这才是作为开发者在实现中需要去解决的真正问题。另外，若没有认真阅读过Jim Gray的《Transaction Processing: Concepts and Techniques》一书，那么你可能理解的只是InnoDB存储引擎是怎样实现的，而不知道为什么要这样实现。而通常来说，后者往往显得更为核心与重要。
最后，DBA可能觉得读点源码就能提高自己在“江湖”上的地位。诚然某些人，包括我自己在内，通过这些方法达到了提高自己影响力。但是从长远来看，源码的结合是为了更好的使用MySQL数据库，从而在数据库架构设计与应用时给出最好的解决方案。我看过一些博客或微博对于InnoDB存储引擎源码的分析，但是感觉大多存在很多问题，正如前面说的，他们仅仅关注的是如何实现而不是为什么需要这样实现，这又会导致对于源码的理解存在很多片面性。你常会看到这样的抱怨：InnoDB存储引擎这个设计好傻，那个设计好呆等。空谈源码没有任何意义，看源码而不尝试去修改，从而使得MySQL数据库运行的更为高效也不符合开源的精神。数据库本身就是一个存储，没有前端应用的配合是无法单独使用的。因此，个人觉得若有人真的痴迷于数据库的底层开发，其必须与前端应用相结合，否则那最多只是研究生阶段的一个研究方向而已。
因此，MySQL DBA不需要过于相信源码的魔力。MySQL数据库或者说任何一个数据库系统可学习的东西都非常多。Oracle、DB2、Microsoft SQL Server的这些DBA们可能从来没有机会去接触源码，但这并不妨碍他们成为这个领域的专家或大师。至于源码研究，那必须与实际应用紧密结合。MySQL数据库是开源的，我们在做出修改和改进时，也需要向社区进行反馈，正如网易、淘宝、Facebook、Google这些公司所做的那样。
评论关闭。