阿里技术牛人是如何炼成的？记访谈阿里MySQL大牛丁奇

《沉淀》是云栖社区品牌栏目，在品味技术人百味人生的同时，也能够帮助你沉淀技术，获得点拨。工作中，如果有不错的大牛让你受益匪浅，也欢迎通过电子邮件（[email protected]）推荐采访，让更多人受益。我们的想法是：“如果你觉得某个技术挺棒的，不妨品味这些技术人背后的沉淀。”

丁奇认为，MySQL设计简单，非常适合初创公司使用

丁奇（真实姓名：林晓斌），阿里云关系数据库服务内核开发和运维团队负责人，活跃的MySQL社区贡献者。专注于数据存储系统、MySQL源码研究和改进、MySQL性能优化和功能改进。

近日，云栖社区就MySQL之路、技术上的认识、团队管理心得以及如何学习MySQL等话题，对这位MySQL领域大牛进行了专访。

以下是采访正文：

和MySQL结缘源自“脸皮薄”

云栖社区：本科和硕士所学专业分别是？当初为什么要选择走上计算机这条路道路？

丁奇：本科学的是计算机应用，硕士阶段师从叶东毅教授学习数据挖掘方向。之所以走上计算机这条路，是因为我本质上是一个懒惰的人，程序员是一个鼓励“懒惰”和帮助“懒惰”的工作。

云栖社区：在计算机众多分支中，为什么会选择做数据库？

丁奇：为什么会选择做MySQL，这里有个故事。刚开始我也是MySQL的小白，而且2008年的时候不像现在网上有那么多前人经验分享，当时MySQL的问题上网一搜，很少有现成答案。用的时候会碰到各种“诡异”的现象，又没有资料可参考。比如平时一个更新语句执行响应时间都1毫秒，在线上偶尔会出现100毫秒。在贴吧这种对响应速度要求非常高的应用是能明显感知的，这个是必须弄清楚去解决的。

主管问这是什么原因，觉得是自己负责的模块，脸皮薄不好意思说不知道，就说去查下，结果上网搜不到答案。

所幸MySQL是开源的，于是就自己去看源码，也没人可以请教，就硬看。结果居然把那个问题解清楚了。

然后就在内网分享了一下。结果同部门的其他组，像百度百科、百度知道那时候也开始大量用MySQL，他们又碰到了其他的一些问题，发现内网里我写的文章，以为对源码很熟悉，也拿来一起讨论。当时自己肯定是不懂的，但觉得他们提的问题也挺有趣，就又去翻代码研究，然后把结果跟大家讨论，把结论分享到内网，结果成了一个循环。

其实我自己工作中碰到的问题不多的，但是很多人的问题一汇聚，查多了慢慢觉得做数据库底层还挺有意思的。

云栖社区：在百度贴吧那两年半的时间，你主要负责什么？那段时间，有什么收获？

丁奇：在百度贴吧从事服务端开发的工作，当时负责的贴吧权限管理等，需要比较灵活的关系维护。刚开始是用我们自己设计的文件存储来实现的，随着需求变得灵活，我们当时决定用关系数据库来维护。那时候选择了MySQL，就此开始跟MySQL，算起来也有8年了。

那时候最大的收获是学习了严谨的技术态度吧。同时刚毕业参加工作就接触这种超大容量、高并发请求的服务，对自己的技术视野的帮助还是很大的。

云栖社区：后来为什么入职阿里？面试过程顺利吗？

丁奇：我当时在业务部门，研究数据库源码其实是工作时间外的事情，后来觉得如果有个工作可以专心做数据库源码也挺好的。刚好看到当时淘宝核心系统正在招MySQL源码研发工程师，而且是章文嵩博士带的团队，就过来面试看看。来之前的想法是即使面不上，跟偶像见个面说上话也是开心的。

过程还算比较顺利。一个下午就把初面到HR面试走完了。章博士是技术终面，他让我介绍过去在MySQL上做的一些有意思的事情，然后他提出问题。当他第一个问题问出来以后，我差点怀疑章博士也做过数据库内核开发。后来才知道这是他的面试方法：探测长板，就让被面试人说最拿手的部分，找到问题去探讨，看候选人的能力到哪里。这其实对面试官的要求很高，要很快的了解候选人陈述的最拿手事情的项目背景、解决方案，并能够从中敏锐发现问题。

所幸我比较属于会就说会，不会就说不会的类型，没有被当场找到什么破绽。相谈还算甚欢，没多久就入职了。

“第一颗糖最甜”：MySQL多线程复制方案最有成就感

云栖社区：在正明（章文嵩）带领的团队，你主要是做哪些方面的MySQL源码开发？主要成就有哪些？

丁奇：现在来看，也算不了什么成就。放在当时的技术环境还算不错，今天就不值一晒了。比如说，给CDN业务做的TPS优化，从300提升到18000，在当时来看，这是一个比较复杂的存储过程优化，但在今天来看就很正常。

另外，比较有意思的一事是：跟褚霸一起设计MySQL+Flashcache方案。那时候SSD刚在市场冒头，大家还不敢拿来当存储，就是作为二级缓存，拿开源的Flashcache来管理机械硬盘和SSD的配合。最开始的时候测试出来效果不行，其他团队准备放弃这个方案。我跟霸爷就分头啃代码，我看innodb，霸爷看Flashcache。结果分析出来，原来Flashcache算刷脏页阈值是按块的，按照两个源码的设计初衷，默认的那种部署方式就是性能有问题。

有个场景记得特清楚：那时候还在创业大厦那边，凌晨三点的时候改进部署，测试出来的效果跟我们分析代码后的预估相同。那种开心真是无法言喻。在那几天的分析中，也有些额外收益：从霸爷那边偷师学了好多好用的工具。

云栖社区：你曾先后设计了MySQL多线程复制方案、秒杀场景解决方案、高并发控制方案、binlog双写方案和切换连接保持方案等，在这些方案中，你对哪个最有成就感？为什么？

丁奇：要说成就感，这些都有。但是要说“最”的话，还是多线程复制。原因可能显得比较微妙，就像人家问100颗糖里面哪个最甜，大概是吃的第一个最甜。并行复制方案现在已经烂大街了，社区已经有4种以上的并行复制方案，但6年前这块却比较空白。

之所以能在6年前做出这样的方案出来，主要还是因为阿里这个平台。当时淘宝的业务发展非常迅速，需要做读写分离，但是有延迟的备库无法提供业务查询。我“潜伏”在各个业务群，发现几个大业务都在讨论这个问题。就自己分析原因，两周写了个版本，拿去DBA团队推销后，发现效果还不错。当自己的方案保证没有延迟的备库提供业务读，进而支持业务发展的时候，那一刻很有满足感。

经验分享：复杂系统改造功能实现不难，难的是如何证明没有引入新的错误

云栖社区：在MySQL源码开发上，有没有遇到什么困难？都是如何解决的？

丁奇：对于一个复杂系统做改造，相比于实现功能，更大的困难是如何证明没有引入新的错误。这种要求7*24小时服务、管理数据的程序，修正错误的成本是非常高的。

对于这些困难，除了规范研发、代码Reivew流程外，我们还增加了一些额外措施来解决，比如，对于Bug修复和通用功能，我们会将Patch提交到社区。这样一来是回馈社区，二来可以收到一些反馈，最大的好处是如果官方吸收了Patch，我们就减少了维护工作量。

另外，我们也有一整套完善的自动化回归测试、稳定性测试、系能测试、崩溃恢复测试和集成测试系统。主干最新代码更新后1小时内就会部署到这些系统中测试。

云栖社区：在MySQL管理、性能调优和高性能架构部署上，是否有什么好的经验分享？

丁奇：这个问题有点大，我就说一个点吧，关于可诊断性。做数据库运维的同学更多的强调的是可靠性、稳定性、性能等。其实不论是支持云服务，还是维护内部服务，可诊断性是体现一个运维系统成熟度的指标。

可诊断性包含但不只是我们常说的监控。以MySQL为例，除了binlog记录操作日志外，是否有系统能力记录所有的读写操作、是否有系统能力记录至少半个月内的链路状态随时备查？以及每个语句精确到微秒的起止时间，执行过程中的资源消耗等。

拥有这些数据只是基础，重要的是要有对这些数据做实时分析的能力。一个简单的问题是：作为一个DBA，如果你的业务方问你三个小时前，为什么CPU 100%持续了5分钟，你和你的系统有没有能力在2分钟内给出答案？

云栖社区：后来你开始维护阿里云RDS，能说说维护云上和本地的数据库主要有哪些差别吗？

丁奇：最大的差别是我们已经接触不到业务方。云服务的本质是提供基础服务，用户拿到一个MySQL实例，就可以按照业务需求去使用。

而DBA的同学们都知道，DBA有一个重要的工作是做业务架构讨论、业务评审、容量评估和SQL审核。因为这些都可能影响一个数据库的运行状态和服务质量。

但是在云上面，就没有接触业务方的机会。我们不再知道用户什么时候会上一个新业务，新业务里面包含多少全表扫描语句。这对我们的诊断系统、主动运维系统还有售后服务体系都是一个很大的挑战。

云栖社区：MySQL分支之一的AliSQL有什么特点？

丁奇：AliSQL分支上的特点是安全性和高性能。在安全上，我们有数据加密存储方案。通过修改源码，堵住了通过MySQL提权获取本地文件系统权限的关键通道，在安全性上我们做了很多改进的工作。

高性能一直是AliSQL的标签。从阿里自身业务维护开始，积累的性能优化经验都体现在AliSQL上，我们在执行计划、io优化、压缩优化上做了大量工作。

新增的功能也是AliSQL的一大亮点。我们有内置的支持秒杀场景的方案、有限制导出数据时单线程性能消耗的语法、高效清空线程占用资源减少内存消耗等功能。这些都是在长期服务内外部客户时，从需求中抽象和实现的功能。

团队管理遵循的原则：对他们好、换位思考

云栖社区：你现在负责ApsaraDB for RDS、ApsaraDB for Postgresql 开发和运维；ApsaraDB for SQLServer 运维、基础配置团队，能否分享下你在团队管理上的一些经验？

丁奇：我自己是从一线工程师慢慢开始带团队的（好吧，其实现在也还是一线工程师），没有专门学过管理，我遵循的原则主要是两点：1.对他们好；2.换位思考。

我经常想自己刚工作的时候，希望得到主管什么帮助，然后就知道该怎么做了。

工作的安排是非常重要的。我给同学安排工作的时候的指标有以下几个：

首先是“踮脚尖、能到达”。不能给太难的，尤其新人，否则会有大的挫败感，也影响项目进度。不能给太简单的，程序员最怕的是没成长。要让同学能用现有的知识，再多学一些新东西，最终能完成。

然后是“有领域，成专家”。工作中的安全感来源于自己的专业性。谁都希望完成工作的同时，把自己的厚度作起来。每个同学要有一个能够做深的事情，这个领域不一定要很大，但是在这个领域里，他就是最专业的专家。

还有一点是“可持续，有发展”。这说通俗一点就是，这个工作可以支持有能力、主动学习同学把自己的专业领域做大做深，还能支持他晋升。

由于主管的信息和资源更多，对于应届生或者工作时间较短的新人，上面几点我觉得并不难做到。

我的团队里面还有好多像德歌、彭立勋、印风、玄惭这样的高级专家，管理这样的专家其实也是摸着石头过河。我觉得最重要一点，是要承认他们有很多比我厉害的地方。主管这个时候的优势只有一个，就是信息更多。多跟他们交流，说明他们的能力与团队目标匹配的地方。这些专家们就会发挥自己的能力，帮助我把团队的能力从各个方向强大起来。

团队跟人一样，是有气质的。在气质改造上，团队比人有优势。一个人要改自己的气质是很难的，而团队的气质是可以由很多人来互补的，由这些专家帮主管补上。章文嵩博士说过一句话，团队主管不需要证明自己的能力，只要证明团队就可以了。

MySQL设计简单 非常适合初创公司使用

云栖社区：对比其他关系型数据库，能否分析下MySQL的优缺点？

丁奇：先说优点吧。一个是方便上手，一个是现在网上资料多。很多问题，现在上网都能找到现成的答案和经验，这就非常适合创业公司使用。毕竟大家还是看重业务，并且一开始也不会有很资深、很专业的DBA或者内核开发团队的配置。

缺点就是跟其他的数据库相比，能力还是比较简单。MySQL设计之初的出发点就是为了简单。虽然Oracle也在给MySQL发展各种能力，比如全文检索、GIS等功能，但是相比于PostgreSQL，这些功能还是有差距的。

云栖社区：MySQL5.7开始也兼容josn，对数据库的未来怎么看？

丁奇：MySQL有一个很好的引擎插件架构，这个就保持了增加各种能力的机会。官方5.7兼容json，5.6开始兼容NOSQL接口等等，就是为了把MySQL能力发挥出来。

后面几个大的数据库方向基本上还是朝着超大容量、分布式、HTAP的方向走吧。

云栖社区：从事MySQL开发，需要具备什么哪些知识储备？

丁奇：首先数据库的基本原理还是要了解，比如常见的存储数据结构、内存淘汰算法等等。语言方面MySQL是C/C++。

然后是最好有MySQL使用经验。当然如果到我们团队，即使没有经验，问题也不大，对于新人我们一开始就安排一些基本操作的练习，在线上值班过程中也会了解用户的使用方法。

其实最重要的是学习能力，其他都好说。

不建议一开始就看MySQL手册

云栖社区：你认为该如何系统地去学习MySQL？

丁奇：其实这个还是跟每个人的工作有关。如果是一个只有语言基础的新人，除了我上述说的了解基本原理以外，我觉得比较快的思路是参与一些比较简单的功能开发。不论是社区还是所在团队的需求。这样你在完成过程中会对所涉及的这部分会有清晰了解。

之后就顺藤摸瓜把相关的知识点弄清楚。基本上是一条线的感觉。

在有很多线的时候，就差不多是一个网了，这是一个很长的过程。到了网的密度很大的时候，就开始看MySQL手册，这时候会把“网孔”补上。

我个人是不建议一开始就看MySQL手册的，得有实战经验以后，去吸收才有效果，看了不会忘。

云栖社区：MySQL源码有上百万行，在阅读MySQL源码上是否有些属于你的诀窍？

丁奇：可能每个人有自己的学习复杂系统的路径，我自己是按照“带着问题去调研”的心态去看的。

当你处于要从源码中找出答案，来解心中疑惑时，一来有驱动力，二来是解决以后印象会很深刻，也有更多乐趣。

跟数据库源码打交道总体来说是一个很枯燥的过程，如果你试过不稳定复现多线程逻辑错误debug就知道。所以有时候我开玩笑说什么样的人适合做数据库源码开发，就是没debug出来你很难受，查出原因时那个高兴劲儿能支持你又继续枯燥好久的那些人。

云栖社区：上段时间正明（章文嵩）离开了阿里，你也和正明共事过一段时间，能否从个人角度评价下他？

丁奇：这里引用正明离职时候，我在朋友圈发的内容：

“我的偶像、导师和引路人。有一种人是你远看有光环，靠近更能感受他的魅力。淘宝核心系统是一面旗帜，历经种种变化，但旗帜一直在团队里流转。很庆幸有那一段经历，跟着章博士，做纯粹的技术和技术人。”

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。