某公司开发人员对该公司 DBA 不愿意从 Oracle 转到 MySQL 评价说「读点源代码会死吗?」
我看到该信息后评论到「能读源代码有个屁用?」 这有些偏激，读代码当然有用，不过读懂代码只是锦上添花的事儿，并不代表能管理好数据库。
就我对 DBA 群体的了解，不愿技术转型的原因典型可能在于:
1. 不少 DBA 的「不愿意」其实是对对行政意志的抗拒. 一个大型团队里面，的确要经常面对并且服从各种决策，不过，如果技术决策无视具体环境，违背了客观规律，完全是出于一两个人的好恶的话，那么对于整个团队来说，并不是好事情。理性的人一定会提前发出自己的质疑或是忧虑。
2. 也有是出于对 MySQL 的「不信任」。这几年 MySQL 有了很大进步，开源社区对 MySQL 的改进也相当好，但是，缺陷还是很明显的，比如，对于联机维护的支持能力至今还是不够的，尤其是对于需要支撑密集并发事务的网络应用来说，达不到工业强度。「可靠性」有的时候比「好用」或是「便宜」什么的更为重要。或许有人不信，拿 Facebook 来反驳，人家不是搞定了么？没错，Facebook 搞定了，但是记住，Facebook 的产品业务类型跟贵公司业务是一样的吗? 如果 DB 本身无能为力，你能从架构角度保证不影响业务呢? 另外，去看看 Google 为什么要开发 F1。
3. 对于某种「不确定」性的恐惧。对于一个自己暂时无法掌控的事物有排斥感，这也可能是人的某种自我保护的天性，超出了自己的「技术舒适区」，担心自己被淘汰或是价值被稀释。如果遇到持这种想法的人，倒是可以对他激励一下，「不都是数据库么?」小马过河，试试深浅再说。
4. 或许还有其他原因，不一一列举。
不过，不管什么原因，「读点源代码会死吗?」这种话都类似于体委主任要刘翔顺便去跑个百米比赛一样，不都是田径短跑么(原理都没变，不都是数据库么)？跑快点就行了嘛 ... 读懂 MySQL 代码的人一堆一堆的，能给 MySQL 提交 Patch 的开发者估计在各大公司也不在少数，但是如果几十台上百台服务器崩溃掉，整个技术团队都看着你的时候，你能气定神闲的分析代码然后写个管用的补丁出来么? 这个时候，可没有人会提 「 MySQL 给公司解决了多少成本」，管理者会暂时忘了那事儿，他这个时候关心的是「可用性」了。
作 DBA 和做 Coding 是泾渭分明的两种思维模式，并无所谓高下之分，会写代码的没必要看不起做运维的，掌控数据的也别看不起做功能实现的，都是看人担柴不费力，如果你是真的去经历一番，就会得出另一种结论。
PS. 这个话题还会引出另外值得讨论的话题来，比如「技术决策的是与非」，今天日子特殊，等我有空再写一下。
--EOF--
