这难道是数据库领域已经不需要理论知识扎实的人才了么？其实不然。在数据库行业中，刚入门的新手渴求的是一本涵盖全面的工具书，对理论类图书大都是望而却步；而已经摸爬滚打十几年的老手们，凭借丰富的经验和阅历，足以满足企业研发所需，自然就不需要这方面的书了，所以数据库理论类的书籍较少。

入门菜鸟希望得到老鸟的经验，国内的图书基本满足了入门的需要。

经验丰富的老鸟希望深入原理、深入代码让自己百尺竿头更进一步，可是这方面的书籍太少。

国内数据库原创书籍，深入到原理和源码层面的，经典的有《MySQL技术内幕：InnoDB存储引擎》、《PostgreSQL数据库内核分析》、《数据库查询优化器的艺术》这几本书，极高的质量和极佳的口碑为中国数据库界增色不少。

而2017年出版的数据库图书中，《MySQL运维内参：MySQL、Galera、Inception核心原理与最佳实》销量较好，《数据库事务处理的艺术：事务管理与并发控制》一书则直接深入到数据库最核心的技术——事务处理层面讨论了并发访问控制等核心技术，这种有深度的书籍折射出国内数据库研发的水准在向最核心部分攀登前进。

站在2017年尾，数据库界更加期盼，未来有更多高质量有深度的数据库原创书籍，来推高国内数据库研发、运维的水准。因为我们看到，国内数据库研发的团队在日渐兴旺。

4.数据库发展小故事

本篇是发生在2017年的小故事，故事的选取，有一定的随机性，未必能代表数据库界的整体情况。放在这里，我们希望能通过研发、运维这么几朵小小的浪花，折射几点太阳的光辉。

4.1 盖老师深度思考的浪花

Oracle 18c，是一个时代的终结。这是盖国强老师在2017年的的感悟。

2017年10月1日，盖国强老师在旧金山OOW大会现场，感受了Larry Ellison发布Oracle Database 18c产品的盛况，18c被称为数据库领域的第一个自治产品，能够实现自我驱动、自我安全和自我修复，事实上就是最大程度的减少了人工的参与。

业界在感叹技术进步的同时，也存在一股淡淡的忧虑和哀伤，因为一个重要的岗位 - DBA可能不再重要，或者不再被需要。

而事实上，盖老师认为更重要的变化是18c这个版本，从12c到18c，Oracle公司改变了数据库的命名策略，以后每年都将发布一个以年为单位的版本，例如19c，20c，这，意味着一个时代的终结。

传统的商业软件迭代，通常以数年为单位，研发一个目标明确、更新众多的发布版本，而这种方式在快速变化的互联网时代，已经过时，用户习惯了快速看到新的变化、快速感受、快速试错，从产品研发到产品发布，一切都在加速，显然Oracle的这一变化就是在适应时代，期望以快速的迭代降低让用户长时间等待的风险。其实无独有偶，微软也已经宣布Windows 10将是最后一个版本，同样改变了重量级大版本的发布模式，变革为小版本快速革新。传统大规模商业软件的运作方式正在改变，Oracle和微软都在通过云平台去重构两家公司的产品输出形态，当一切都可以通过服务的形态输出之后，商业和开源的界限事实上就已经不存在了。

基于此，盖老师在思考：在企业级数据库领域，下一个时代是什么？

盖老师认为下一个时代是自动化、智能化的时代，从靠人去解决问题，过渡到靠产品、靠架构去解决问题，让数据库回归存储的本质，新的时代已经开启。

这是一朵深度思考的浪花，浪花背后是对产业前进之路的探索。

4.2 向MySQL提交bug的小浪花

2017年9月，鹅厂实习生晓宇同学向MySQL官方提交了BugID为87637的一个有关缓冲区刷脏页时消耗CPU资源严重的性能bug，并给出一个解决了涵盖多种场景下消耗CPU的patch。

Bug hunter并未重视这个有场景描述有代码分析有测试数据的bug，反而修改bug状态为“not a bug”，晓宇同学在bug被标识为“not a bug”后，有理有据地指出bug的成因、patch的原理等，然后有礼貌地再次打开bug，请MySQL官方重视。这样的过程，反反复复，反反复复，竟然反复了五次。直到一个月之后，持久的争执引起InnoDB研发老大Sunny Bains的关注，Sunny Bains认同了晓宇同学的patch，这场拉锯战才宣告结束。

现在，这朵小浪花已经随潮而去，但是这么一朵小小浪花，却能折射出较大的意义：

1. 国内研发人员的素养和MySQL官方的傲慢形成了对比。

2. 当世界并没有足够重视国内数据库技术研发的力量时，我们可以用实力说明事实。

3. 现如今，我们还需要积极参与开源社区，提交Bug与patch，甚至提交有影响力的模块/WorkLog，这样才能逐步扭转“国内数据库尚未被国际认可，尚不达先进水平，发展尚任重道远”这样的现状。

在采访这个小故事结束时，晓宇所在团队TDSQL研发负责人说：TDSQL源自MySQL，我们鼓励TDSQL的组员为社区多做贡献。晓宇的这个故事，是我们团队的一个小事，相信更是中国数据库界的一个小事，但是勿以善小而不为，积善助善为这个世界多做一点好事是有意义的。

这，应该是一种情怀吧。

4.3 规范运维的小浪花

数据库运维中会制定各种流程和规范，很多运维同学不以为意，觉得太繁琐，殊不知这些都是在大量的失败经验中总结而来，是运维保障的基石。

让我们用发生在建荣同学身边的一个故事，一起感受DBA的生活。

公司每隔一段时间会发布一些活动，来提高人气和热度。

而发布一个活动的常规流程是这样的：

1. 开发同学提交了一个DB变更，会打包发布到了ftp中。

2. DBA会从ftp得到指定的数据压缩包，解压把数据导入数据库。

3. 测试同学会验证测试，验证后上线活动。

4. 业务运营的同学会跟进活动，做活动反馈。

结果有一次却发生了一个诡异的问题。

活动已经接近尾声，运营的同学才发现数据比以往差了很多，然后测试的同学排查发现导入的数据比预期的少，然后追查到DBA这边，DBA发现数据导入是成功的，然后继续追根溯源，发现开发同学提供的数据更新包和DBA导入的包大小不一致。

经过一番排查和验证，发现原因就在于开发同学上传到ftp中的文件因为网络的原因，提示上传成功了，但是文件是不完整的，DBA解压的时候就少了很多数据，后续测试，运营跟进活动都会受到影响。

我们做故障复盘的时候，发现虽然整个流程是完整的，但是很多环节还是没有形成闭环。

怎么改进呢？

1. 第一就是使用md5的校验码，能够做到文件校验。

2. 第二就是通过平台化管理来杜绝人为问题。

3. 第三就是业务的及时跟进。

所以说很多问题都不是纯粹的技术问题，要靠一套完整的制度和流程来规范和完善，规范本身虽不能够解决问题，但是能够减少出问题的概率。

5.跨年之夜，我们一起进步

随着云计算产业的发展，数据库云化趋势已经形成，而云化对大规模的数据库群、数据库集群等的运维提出挑战，于是数据库智能运维因需而生，而Oracle在AI火热的环境下，用自治数据库一举点燃了本年度数据库燃爆点。自治数据库已经不再是自动运维的数据库，而是智能运维的云端数据库。