从职业发展到技术建议，谈DBA“特种兵”的修炼之道

2017 年 7 月 17 日 DBAplus社群 杨建荣

本文根据杨建荣老师在〖DAMS 2017中国数据资产管理峰会〗现场演讲内容整理而成。

（点击底部“阅读原文”获取杨建荣演讲完整PPT）

讲师介绍

杨建荣，DBAplus社群联合发起人。现就职于搜狐畅游，Oracle ACE、YEP成员，近10年数据库开发和运维经验，擅长电信数据业务、数据库迁移和性能调优。持Oracle 10G OCP、OCM，MySQL OCP认证，《Oracle DBA工作笔记》作者。

今天分享的内容是技术发展解读，还有一些学习的建议，其实更多的是一些点，我希望把这些内容串成一个面，让大家通过我提供的这些小故事、例子、技术小测试等能有所感悟，我的目的就达到了。

首先分享的是一个简单的小问题，这也是我很早之前做DBA时碰到的一个坑。

说简单些就是把MySQL重启一下，而当时碰到这个问题的背景比较复杂，有一个同事要离职了，他说这个库跑了很多年都没什么问题，有一个主从的环境，都是正常的，其实不用管了，好多年了一直没有出过问题，他这么一说，我就不敢去动了（其实也是幼稚）。结果这个环境没有多长时间，有一天我们收到一个报警，说这个从库服务器宕机了，要保证数据的高可用，于是准备搭建一个备库，却发现主库的binlog没有开启！所以那个备库其实是一个假的备库，而这个问题真是细思恐极。到底是流程交接的问题还是个人的问题，都有，很多问题如果细剖起来有五花八门的问题，如果没问题都万事大吉，所以在这种情况下我申请了维护时间重启主库。

但是发现重启之后数据库起不来了，数据字典也有一些问题，这个也花了一点功夫修好，算是有惊无险。但是后面有一些应用的同学说数据库连不上，就查各种原因，一个看起来很简单的重启竟然带来了这么多的问题，最后排查发现有一部分应用连接之前就有问题，也是通过以前的日志去推理。所以一件很简单的事，最终引发出这么多的问题，这是我入行碰到的一个印象很深的问题，也是一个比较大的坑。

所以，通过这个事情我做了一些基本的反思，作为一个新人，不光是要基础知识掌握扎实，你还需要去掌握一些其它方面的技能，比如沟通，比如学习方法等。我自己也开了一个微信公众号，经常有很多朋友在后台留言，有些是刚入行有些困惑，有些是入行有些年后有些迷茫，会问我怎么办，怎么样去调整一下自己的状况。

对于学习，我引用Oracle行业非常有名的专家Jonathan Lewis说的一段话，收录在《Oracle的核心技术》里面，有一段话我看了以后非常受启发。这也是我给大家学习的一个基本态度：

对我们绝大多数人来说，他认为在这种学习中始终要懂得去权衡，很多东西对于数据库来说大体知道引擎的工作，有一些不必要的细节就不用特别细究，注意，不要浪费时间去研究不必要的细节，而是要找到折中的办法，使你所掌握的知识足以预判Oracle在你没见过的场景中会怎样做。我更倾向于从实际问题出发，能够牵扯出来更多学习的点，然后逐步去深入，由此达到一个面，最终形成自己的知识体系。

明确了学习态度，我们来看看一个技术发展的基本情况，以下是MySQL被收购后，开发团队成员的一个去向图。

而MySQL被Oracle收购后的发展大体是这样的一个比例，右边的开发人员是Oracle公司的，左边的则是原来的MySQL团队的。

过了些年，我做了一个标识，在MySQL8.0中会最终抛弃MyISAM，InnoDB发展很快，优化器也有了很大的改进，通过这样一些小的细节你会发现整个技术的发展非常快，但其实也就短短几年的时间。所以通过这些我们可以看到，技术是不断发展的，在这个过程中，我们就需要像司机一样，不断根据道理情况来适度调整学习的方向，不要花太多的时间在一些废弃、过时的特性上。

因为我也从事DBA工作，经常跟很多同学交流，有些同学不了解我们DBA做什么，其实让我们很尴尬。很多人说DBA不就是建一个表，修改一下数据，听起来好像也没什么特别要做的事情，下面我通过以下五个层面去解读一下DBA工作内容和技术建议。

一个是数据管理，这个是基本功，一定要做好做深。架构设计方面，就是数据库架构师，要学会如何从应用设计需求去做一些工作，如果能把那个“库”字去掉就更好了。开发扩展，其实对DBA比较高的要求，不光有脚本开发能力，还有掌握开发语言。技术前瞻，可能你的技术目前没有问题，但如果从前瞻的角度来看，可能在几年之内会有什么样的发展和隐患。最后是综合能力，我会举一个Oracle迁移的例子，告诉大家怎样去做一个迁移的优化。

总体来说，现在对DBA的要求也在变高，如果能够把DBA打造成一个“特种兵”的角色，对个人和公司都是双赢。

1、数据管理

MySQL无法创建表的问题，对DBA来说很简单，用脚本创建一个表，这是我一个同事碰到的问题，他说这个问题好奇怪，有个创建表的需求，创建了10多个表，结果有2个表创建不了。我的一个猜测，可能是大小写的原因，可能是数据类型、触发器、外键导致的，也很有可能是一个Bug，而根据perror的结果来看可能是属于外键，不过暂时没有找到任何线索，所以我们逐步排除。

我做了一些简单的测试，发现给这个表后面再加一个S就可以了（其实就是给表改了个名字）。或者是改用小写，当然开发的同学不同意了，说不太好改，而且问题没有根本解决，只是把这个问题规避了一下。

我们又做了一些排查分析，最后发现开发同学是用Navicat工具间接导致，这个工具可以做查询，比较方便。不是说这个工具不好，而是在变更前，这个工具默认会加这么一个选项，Setforeign_key_checks=0，这样外键的检查就不生效了，所以在部署脚本的时候，有两个表始终有问题。当然这个案例我们也做了总结，一个是第三方工具多多少少可能会有一些影响，需要评估。第二，开发同学提供这个脚本，当时提供的列表得不是很完整。比如说变更的表12个，他只提供了10个表的变更，他认为另外2个表已经有了就也不提供了，结果最后发现它们之间有一些关联，导致了一些问题。

所以很多时候我们做这个工作还是不断地去规范，有同学说这个问题有一定的局限性，那我们不用第三方工具，那我们再来一个更简单的，我们看一下MySQL字段长度怎么去设计。

2、架构设计

MySQL里面的页是16k，这个存储是用IOT的方式存储，字符集很丰富，有latin1，支持火星文，还有一些gbk还有utf8。如果你是gbk，表里含有一个字段，可以指定为32766字节，如果再长一些就不行了，gbk类型，行长度是最大为65535，则varchar列的最大长度算法就是（65535—2）/2等于32566.5。

下面是一个简单的小测试，能够马上看到效果。

而对于latin1，长度范围会广一些，如下图所示。

而对于utf8，因为对应3个字节，所以算下来长度范围就小一些，简单测试如下图所示。

所以我们在工作时，开发同学提供一个语句，你看起来也没有什么差别，但是前期设计时一定需要把这些细节考虑到。当然大家的表不可能是只有一个字段，这时候牵扯到这样的一个问题，那就是更实际的问题，我来抛出一个问题。

如果是gbk字符集，含有下面的几个字段，则memo字段是varchar类型最大长度是多少，这是一个很常规的问题，如果把这些连接起来去演算一下，数值型是4个字节，字符型乘以2，含有字符型的长度小于255，所以减去1即可，这样下来就是32743。

有的同学说我们这个表设计字段也不多，可能几个就可以了，那行，我们继续聊一个更有挑战的，有有一些公司的开发同学对binlog有一些需求，他们会用解析binlog去做一些基本的搜索，他们去做的时候有个疑问，对于数值类型，是分为有符号和无符号两种，那怎么在binlog去体现这个差别，这个就需要去验证一下了，我们还是拿出基础知识，下面是一个数值类型的范围表。

3、开发扩展

其实数值类型还有更多对于这样的情况binlog它是怎么去展现的，是有符号还是无符号的，你把这个搞明白，数据处理的时候就有思路了，我们来看看进制转换。

我简单做了一个小的测试，—1是十进制的，另外一个是最大值，如果从10进制转成二进制，就是一个数据临界点，他们两者转成二进制以后得到这个值都是一样的，看起来这个—1和最大值是没有差别的，但是如果是实际的场景是天壤差别，这个差别非常大。

在此我们可以简单做一个小测试，创建一个表，加两个字段，我们把这个最大值和—1都插入进去，会生成一些binlog记录，我们解析binlog，来看看binlog里面是怎么处理的。

Mysqlbinlog解析后的内容如下：

到这里我们能够得到一个基本的结论，有符号和无符号的数都会按照无符号去处理，如果你有这样的开发需求，你就需要去了解这样的一些边界。

4、前瞻

再来看看前瞻的内容，还是一个四两拨千斤的小案例。

是关于时间类型的默认值的问题。有一个同学提了一个数据变更，他说自己测试没有问题，但是我这边线上环境运行的是有问题的，最后发现他的环境是MySQL 5.5，我是MySQL 5.6，同样的语句下，在MySQL 5.5有问题，MySQL 5.6没问题，显示是时间字段在不同版本的处理方式不同。

所以能够根据很简单的测试总结出来，是动态的默认时间值的支持不同。如果细分一下，会发现datetime和timestamp类型还是有很多差异的地方。

大家如果观察得比较仔细，会发现这个数据类型是datetime和timestamp都是时间字节，datetime是8个字节，timestamp是4个字节，大家去设计的时候也要去考虑。这个问题的解决简单总结一下，一个是对于版本为了保持兼容，那我就不需要加默认值了，第二个对这个问题做了一个权衡之后，他们觉得用timestamp目前可以解决我碰到的问题。

5、综合案例

最后是一个综合案例，我就说一个Oracle数据迁移的优化方案吧。

简单分享一个迁移的小案例，这是一个小机的环境，迁移到X86，数据量倒不大，800多G，但是这个环境硬件非常老，跑了很多年了，也没有什么业务增长，大多数是数据查询。这样的一个业务又是一个全局的核心业务，迁移的工作最终是拖了很多年，而在后期迁移的时候，还是碰到了很多纠结的问题。数据迁移我也想了很多的方案，因为版本比较老，维护窗口时间很短，就想怎么尽快迁出来。我们当时做了一些更细节的评估，这样一个数据库，发现数据段和索引段占的比例是比较高的，占到了90%以上的比例，剩下的是数据字典和其他数据，不到10%，如果是这样的一个平滑迁移的话，把索引段这部分的工作先做好，整个迁移的数据量少了近50%。

所以我们不断拆分，于是有了下面的这个比例图。

我们发现这个库里大概有20多个表是相对比较大的，一些其他的表是比较小的，基本上占到了90%的一个比例。对20个大表又做了一个基本的评估，我们发现这20个大表里面有3个表特别大，占到了整个数据量的90%。这几个大表虽然大，但是做查询比较多，基本没有写入，最后用OGG的方式去同步，占比很高的数据同步工作就做好了，而对于剩下的17个表，因为单表数据量也不大，就采用物化视图的prebuilt方式来创建，达到增量刷新的目的，当然如果用OGG同步也是可以的，里面有一些其他方面的考虑。所以这样的一个迁移，到了后期就逐步拆分，归类，最后的迁移只需要真正迁移5%的变化数据。所以说数据迁移没有最好的方案，只有最合适的方案。我讲了这么的案例，很多都是比较小的案例，看起来挺简单，数据类型都是比较小的案例，能够通过这些小的地方能够不断的去打磨自己。

掌握了上面的技能，你的竞争力就会大大增加，公司会愿意把一件事情交给你来负责，而不是说让你去做某一个很具体的工作。所以我再来说说人才的评价标准。