题记
怀晓明是ITPUB论坛版主，同样成长于论坛的网络时代，他的开发经历以及卓越的个人学习能力，成就了他精深的SQL造诣。作为ITPUB论坛几届SQL大赛的评委，他在组织方面的能力也得以显现。在本章的内容中，我们汇集了他在成长过程中的学习、思考、技术积累和总结分享等经验，希望他的思路和方法，可以为大家的成长提供一定借鉴。
10.1 我的职业生涯
我2001年大学毕业，起初在大型国有IT企业工作，主要做电子政务方面的项目。第一家公司做了6年，从售后工程师到程序员再做到项目经理，第二家公司和第三家公司都担任项目经理兼系统架构师。那时候我看到移动互联网的迅猛发展，希望接受更多的挑战。2011年，我毅然投入到互联网的大环境里，加入了一家创业公司。在此期间，我主要负责全面的技术管理工作，兼做数据库开发方面的技术工作，目标是使用较低的技术成本实现高效率的系统。随后我加入了云和恩墨公司，主要职责是利用自己丰富的SQL能力、架构能力帮助用户进行系统优化。现在更丰富的实践积累让我有能力帮助更多的用户实现更优化的架构。从2002年注册ITPUB开始，我的Oracle方面的技术知识基本上来自官方文档和论坛（包括在积极为网友解决问题时学到的知识），ITPUB见证了我的成长和梦想。我在论坛上的网名是“lastwinner”，有人说是“最终赢家”的意思，其实不是。这个名字的含义是“只有坚持才能成为最终的胜利者！”——To last long to be the last winner! last除了“最后的”含义外，还可以作为动词“坚持”去使用。我更喜欢这个含义。这句话也送给大家，希望大家都能在自己的岗位上通过坚持不懈的努力取得更好更优的成绩！
10.2 运维的现状及发展
目前运维面临一个重大的问题，很多公司并没有意识到提高开发技术可以有效地提高系统性能，即使有的公司意识到了也没有资源去做。我认为这个现象的本质是老板们没意识到提高开发技术其实是可以降低开发和后期运营维护成本的。有可靠的统计数据指出，80%的数据库性能问题出在攻城狮编写的SQL上。而在这现象背后更根本的原因是，没有可胜任数据库开发工作的攻城狮！一旦出现系统性能问题，大家第一反应就是去找调优高手来优化SQL，久而久之，这就成了一个习惯。老外有句谚语——一天一个苹果，你就不需要医生了，这说的就是预防为主。转换下思路，如果提高了攻城狮们的开发水平，甚至是配备了专职的数据库开发工程师，那写出较高质量的SQL就不是什么难事儿。这样就避免了多数性能方面的隐患，自然就降低了后期出现性能问题的概率，也免去了大量请人做调优的成本，而提高攻城狮开发水平的成本并不是特别高，何乐而不为？ISO-9000告诉我们，质量是生产出来的，不是检测出来的。同样，高质量的SQL应该是开发写出来的，而不应总是通过DBA去调优出来。无论公司是否意识到、是否有资源去做，提高开发技术尤其是数据库端的开发技术都是大势所趋，不去迎面解决问题而装鸵鸟的做法是不可取的。
10.4 如何提高数据库的开发水平
提高数据库的开发水平是一个系统性的工作。简单说就是理论与实践充分结合，只懂理论或只会实践是不可取的。要学会用理论指导实践，通过实践验证理论，在实践过程中不断丰富理论知识，在理论指引下不断提高实践能力。我认为一个好的数据库开发者应该具备以下品质。
- 掌握SQL基础知识和数据库基本理论。这有助于理解SQL是如何运作的，什么样的SQL会跑得更快。可以通过学习相关白皮书或者技术文档掌握。
- 学会提问。提问是一门艺术，无论学什么都需要掌握这门艺术。能够准确地描述问题其实是解决问题的关键。
- SQL中高级知识。这能让SQL成为你的有力工具。可以通过阅读官方文档，经常参与Itpub的数据库开发版块学习从而提高自己的水平。学习时不要想当然，就像trim并不等于rtrim＋ltrim，认真读文档的人都知道。
- 掌握至少一门相关的开发语言。Java、PHP等都行，这有助于你从另一个视角来认识数据库开发。
- 一定的数学能力，最好具备高中以上的数学知识。良好的数学素养可以为你带来新的思路和方法，有助于提高开发能力，并能帮助你理解。
- 一定的科学素养。类似于“某月有5个周五、周六和周日，这种现象823年才出现一次”的论调，或“1582年10月5日~14日这10天是不存在的”等要一眼就要能看穿是假的（或者会通过程序去证伪）。
当然，学习任何技术都是没有捷径的，最重要的是勤奋和努力，要静心学习，切忌浮躁。脚踏实地才能学得真知。做到以上几点，假以时日，成为高手不是梦。
10.5 DBA面临的挑战
如果技术进步，部分DBA失业，那只有一个原因——落伍。活到老就要学到老，而在技术的世界，学到老才能活到老。技术进步只会减少重复性的劳动，而且多数还是“体力”劳动。数据库方面的技术进步，将让DBA更加专注于业务方面的考量，发挥出DBA本身应有的更大的价值，但同时也对DBA提出了更高的要求。以前你擅长的工作现在可以轻易被新技术所取代，那你就必须学会新的本领。现实是很残酷的，尽管我们处于文明社会中，“弱肉强食”的丛林法则照样适用。但是机遇总是和挑战并行的，敞开心扉，纳入新知，新时代的弄潮儿非你莫属！要知道，技术进步也会促进新职位的出现，因为技术进步会促进产业分工明晰，这时候DBA必然会分化到各个不同的细分领域，比如“产品DBA”“调优DBA”和“应用开发DBA”等。综上所述，我认为，“应用开发DBA”的群体会越来越壮大，因为这部分群体有强烈的市场需求。而作为常规意义上的DBA，多掌握一些开发技术，会让你的数据库管理更加游刃有余，轻松许多！轻松应对将来的职业挑战。当然这并不意味着运维DBA的价值会减少。相反，性能问题和安全问题一直存在，在大数据与云计算的时代里，这些问题越发突出。**以数据驱动决策的时代里，数据就是企业的生命，因此越来越多的企业开始关注与重视数据。在这样的环境下，能管好数据的DBA****自然会身价不菲。**时代的发展不会淘汰谁，自己不发展才会被淘汰。
10.6 数据库优化的思考
针对数据库的优化，不同层次的开发者考虑问题的思路和角度是不完全一样的。作为我个人而言，会先考虑业务上为什么要这样做，其次考虑业务是否可以简化，再次考虑是通过SQL、PL/SQL还是前端程序去实现才能达到最好的效果（需要综合效率、可维护性、实现复杂度等多方面去考虑），再后考虑具体的算法，最后才去考虑具体算法的实现。而在具体的实现上，先依据自身的知识和经验选择一个合适的算法，并通过合适的SQL去实现要求，检查无误后再考虑SQL优化的事情。一般在经历过大量的数据库开发工作后，基本上一出手SQL的质量都不会差，通常也就没什么优化空间了。需要注意的是，有时候SQL优化仅仅是某几个SQL优化的事，而有时候SQL优化却需要改动技术方案以支撑。技术方案基于开发技术但又高于开发技术，所以掌握了扎实的开发技术，才能将技术方案和相关设计工作这样重要的事情做好。
我举几个工作中的案例。
- 数据迁移。需要从A服务器上的一张将近有一亿条记录的表中抽取数据，将其导入到B服务器中。当时用java来当搬运工，每次生成2 000条数据的xml文件。实测发现每次生成xml文件花的时间大约在2分钟左右。调整为每次生成5 000条数据的xml文件，花的时间大约在4分钟左右，速度没有太明显的改善（规范的上限是5 000条/xml文件，不能再多了）。这个速度很要命，一天才1 440分钟，全部导出完成差不多要俩月时间，这还是在速度恒定的情况下。可事实是随着数据不停地导出，导出速度会越来越慢。经过不断地改进开发方法，包括调整技术开发方案，最终我们将导出的速度优化为每次生成2 000条数据的xml文件只需要2秒，这样一天多点我们就可以将一亿条记录的表中的数据都抽取出来了，这是程序的优化。
- 数据检索。某SQL需要提取出某博文的前200字作为摘要，将其显示在作者博客的首页上。结果开发人员SQL是这么写的。
SELECT blog_id， blog_title， blog_text from blog where …
然后在前端程序里截取blog_text的前200字展示出来。在访问量大的时候，这导致了严重的系统性能问题。一查原因，网络I/O负载过大。调优很简单，SQL改为：
SELECT blog_id， blog_title， substr（blog_text，1，200） as blog_text from blog where …
性能问题马上消除了。为什么？因为改写后的SQL只从数据库中取出少量信息发送到前端，而不是像之前那样发送全部博文到前端，自然就降低了网络I/O，性能自然而然也就提高了。当然，在用户量和访问量进一步提高的时候，就得采取其他的方法了，比如加缓存之类的，这是另外的话题，就不细说了。这是SQL的优化。并行导入。当时我们和别的公司都需要往数据库里导入300G的数据，我采取了多进程的方式导入，结果最快的一次不到7小时就全部导入完成了。而另外那家公司5天了还没导完，双方的服务器配置都差不多，怎么时间差这么多？经过了解，他们采用单进程的方式。这并不是什么高深的技术，但知道和不知道的成本有时候就会相差很多。这是方法的优化。所谓优化，其实就是在充分了解技术之后的灵活运用。
