[名人堂] ITPUB名人堂：ITPUB社区版主lastwinner(怀晓明)带来数据库进阶

作者：gaokeke123 时间：2021-12-13 14:05:56 0 删除编辑

本期我们邀请采访的是具有多年数据库开发与项目管理经验的数据库专家怀晓明先生，社区ID：lastwinner。此大师兴趣广泛，视野广阔，目前专注于移动互联网领域内低成本高成效的系统架构设计实施与团队管理。是一个细心敏锐的Troublshooter，善于辅以搜索去处理解决各类陌生领域的问题。曾获得第一届ITPUB最佳建议奖，在多个大型IT企业多年的工作历练中，积累了丰富的系统架构设计经验，擅长数据库和Web的设计、开发，精于故障诊断与处理，具有丰富的省部级电子政务行业工作经验及项目管理经验。合著作品有《剑破冰山——ORACLE开发艺术》、《Oracle DBA手记2》。

arron刘：
各位PUBer大家好，本期的名人堂采访人物是ITPUB社区版主怀晓明先生，社区ID：lastwinner。lastwinner您好，请简单的介绍一下自己，以及您的工作经验。
lastwinner：
arron刘，您好，谢谢ITPUB对我做此次采访。我的职业经历其实比较简单，从2001年毕业后，我就一直在大型国有IT企业工作，主要做电子政务方面的项目，第一家做了六年，从售后工程师到程序员再做到项目经理，第二家和第三家都担任项目经理兼系统架构师。在工作期间我看到移动互联网正在迅猛发展，我想在这里我会遇到比以往更强的挑战，于是在2011年，我毅然投入到这个大环境里，加入了静雅思听。目前我主要负责全面的技术管理工作，兼做数据库开发方面的技术工作，目标是使用较低的技术成本实现高效率的系统。

我2002年年末在ITPUB上注册的，至今正好是十年。我的Oracle方面的技术知识基本上来自于官方文档和从本ITPUB论坛上学到的东西（包括在积极为网友解决问题时学到的知识），目前就任Oracle开发版的版主，并与好友合著有《剑破冰山——ORACLE开发艺术》、《Oracle DBA手记2》等作品。

arron刘：
我们知道在平时的Oracle开发工作中我们有时候会遇到些BUG，您在开发方面经验又非常丰富，能说说您遇见最悲催的Oracle bug是哪种？您是怎么解决的？
lastwinner：
这个问题很有意思。我曾经碰到过的BUG大致分为三类：
1. 出现ora-00600,ora-03113,ora-07445等错误，导致程序无法执行
2. 执行计划错误，导致很长时间才出结果
3. 由于执行计划错误而给出了错误的结果

第一类很让人无语，明明写的代码没有任何问题，但Oracle就是报这几个错误中的一个。这一般是Oracle的bug导致的，少部分是执行计划错误导致的。一般在生产环境中碰到这样的问题，只能认栽，通常只能换个方式来实现同样的功能，要不然就得换开发方案，但这样的开发成本就会很高了。如果在开发环境中碰到，还可以通过给数据库打补丁来解决这类问题（如果Oracle发布了的话，不过在生产环境上，补丁不是随便就可以打上的，一定要打的话，必须先做充分的测试）。

第二类很使人无奈，不过还好，为什么说“还好”？因为，这至少还能出来正确的结果嘛！这一般可以通过给数据库打补丁、修改参数、添加强制提示等方法来解决这类问题。比如我曾经碰到过Oracle10.2.0.5在Linux 64bit下出的full outer join的bug（类似于官方给出的bug2927071），一个full outerjoin出来结果需要两三分钟，而通过修改参数
alter session set "_optimizer_native_full_outer_join"=force;
后，改变了原先不正确的执行计划，结果一秒内就哗哗哗的出来了，经验证结果也是正确的。

第三类是最悲催的，可以说直叫人生不如死。为什么这么说？第一类bug碰到的话，Oracle会报错，起码能提醒你此路不通；第二类bug碰到的话，起码你本能的可以感觉到这里有问题，就算你没意识到，结果也是正确的，对吧？但这第三类bug，我从9i到10g都碰到过，明明写的SQL没任何问题，但Oracle偏偏就给你错误的结果，还好每次都因细心发现了，及时调整了技术方案，才没导致更大的问题发生。

为此我在论坛曾发起过一个调查 http://www.itpub.net/thread-1717539-1-1.html，结果是三类情况都有不少人碰到过。碰到这些bug并不就意味着你很倒霉，事实上，换个角度看，首先要恭喜你，因为这说明你的sql水平已经达到了一个较高的程度了；倘若你能意识到不对劲，那说明你足够敏锐；再若你还能找到解决办法，那你就很厉害啦！

至于如何识别、解决开发过程中碰到的这类bug，这个话题比较大比较深，以后有机会我再和大家分享。但在这里我需要指明的是，其实很多最终结果不正确的程序，多数都是因为代码本身的问题导致的，而因为Oracle Bug导致的问题只占极少的部分。

arron刘：
看来您挺乐观的，碰到这样悲催的事情也能往好处想。现在好多的公司并没有意识到提高开发技术可以有效的提高系统性能，即使有的公司意识到了也没有资源去做，那么您认为如何做才能改变这样的状况？
lastwinner：
俗话说“树挪死，人挪活”，咱不能因为一块石头堵在前面就非得把它炸开才能前行，绕过去往前走也是一种方法，对吧？

做系统优化其实也一样。系统的性能提升是涉及到方方面面的，从网络、操作系统、数据库、应用服务器到程序，都有提升的空间。现在很多人都知道，最该优化的部分是攻城狮们开发的程序，比如拿数据库的性能问题占比举例，有可靠的统计数据指出，70%的问题出在攻城狮编写的SQL上。而在这现象背后更根本的还在于，没有可胜任数据库开发工作的攻城狮！一旦出现系统性能问题，大家第一反应就是去找调优高手来优化SQL，久而久之，这就成了一个习惯。就好像平常不注意预防疾病，反正病了就找大夫治疗，而你也许不知道在未来某一天，面对焦急的亲属，白衣天使也会无奈的摇摇头，摘下口罩，叹了口气轻声道：“我们已经尽力了，你们准备后事吧……”

很多公司，包括专门做IT的公司在内，的确是没有意识到提高开发技术可以有效的提高系统性能，这个现象的本质关键是老板们没意识到提高开发技术其实是可以降低开发和后期运营维护成本的，这笔账算清楚了，老板自然愿意投入资源来提高工程师们的开发技能。通常不是技术出身的老板是意识不到的，这就需要技术管理者“晓之以理，动之以情”说服老板投入资源。当然，老板投入资源后，技术管理者必须hold得住，要将事情漂亮得完成，看到效果的老板自然就不会存疑了。

对于意识到了但是没技术资源去做的情况，只能用其他资源来换取技术资源了，比如内部培养人才、找外包、从外部请和尚等等。

老外也有句谚语——“一天一个苹果，你就不需要医生了”，这说的也是预防为主。我们转换下思路，如果提高了攻城狮们的开发水平，甚至是配备了专职的数据库开发工程师，那写出较高质量的SQL就不是什么难事儿。这样就提前消除了多数性能方面的隐患，自然就降低了后期出现性能问题的概率，也免去了大量的请人做调优的成本，而提高攻城狮们的开发水平成本并不是特别高，何乐而不为？ISO-9000告诉我们，质量是生产出来的，不是检测出来的，同样，高质量的SQL应该是开发写出来的，而不应总是通过DBA去调优出来。无论公司是否意识到、是否有资源去做，提高开发技术尤其是数据库端的开发技术都是大势所趋，不去迎面解决问题而装鸵鸟是不可取的。

arron刘：
讲了这么多可以说是系统开发人员的技术是很重要的，那么如何能够提高数据库开发水平呢?
lastwinner：
这是一个系统性的工作。简单说就是理论与实践充分结合，只懂理论和只会实践同样是不可取的，要学会用理论指导实践，通过实践验证理论，在实践过程中不断丰富理论知识，在理论指引下不断的提高实践能力。

就数据库开发而言，最好具备如下能力与素质：

1.掌握SQL基础知识和数据库基本理论，这会有助于你理解SQL是如何运作的，什么样的SQL会跑得更快。这可以通过学习相关白皮书或者技术文档获得

2.学会提问。提问是一门艺术，无论学什么都需要掌握这门艺术。这在论坛我专门写过一个帖子来讲述http://www.itpub.net/thread-1348543-1-1.html

3. SQL中高级知识，这能让SQL成为你的有力工具。这可以通过阅读官方文档，经常来itpub的数据库开发版块学习学习，来提高自己的水平。学习时不要想当然，就像trim并不等于rtrim＋ltrim，认真读文档的人都知道。
4.掌握至少一门相关的开发语言，java、php等等都行，这有助于你从另一个视角来认识数据库开发。
5.一定的数学能力，最好具备高中以上的数学知识。良好的数学素养可以为你带来新的思路和方法，有助于提高开发能力，并能帮助你理解。
6.一定的科学素养。类似于“某月有5个周五、周六和周日，这种现象823年才出现一次”的论调，一眼就要能看穿是假的（或者会通过程序去证伪），要知道1582年10月5日—14日这十天是不存在的等等。

总之，捷径是没有的，脚踏实地才能学得真知，做到以上几点，假以时日，成为高手并不是梦。

arron刘：
能不能给我们举一个您工作当中遇见的案例呢？比如说做一个SQL语句的优化之类的，同时给我们谈谈考虑问题的思路？
lastwinner：
不同层次的开发者考虑问题的思路和角度是不完全一样的，作为我个人而言，我会先考虑业务上为什么要这样做，然后考虑业务是否可以简化，接着考虑是通过SQL、PL/SQL还是前端程序去实现才能达到最好的效果（需要综合效率、可维护性、实现复杂度等多方面去考虑），再后考虑具体的算法，最后才去考虑具体算法的实现。我在论坛上回复过一个帖子，表达了类似的思路：http://www.itpub.net/thread-1721650-1-1.html 。

在具体的实现上，首先先依据自身的数学修养来选择一个合适的算法并用合适的SQL来实现要求，检查结果无误后再考虑SQL优化的事情。一般在经历过大量的数据库开发工作后，基本上一出手SQL的质量都不会差，通常也就没什么优化空间了。需要注意的是，有时候SQL优化就仅仅是某几个SQL优化的事，而有时候SQL优化却需要改动技术方案以支撑。技术方案是基于开发技术但又高于开发技术的东西，所以掌握了扎实的开发技术，才能将技术方案和相关设计工作这样更重要的事情做好。工作中的例子不少，先说一个08年时做的一个项目，需要从A服务器上一张将近一亿条记录的表中抽取出数据导入到B服务器上，当时用java来当搬运工，每次生成2000条数据的xml文件。实测发现每次生成xml文件，花的时间大约在2分钟左右，调整为每次生成5000条数据的xml文件，花的时间大约在4分钟左右，没有太明显的改善（规范的上限是5000条/xml文件，不能再多了）。这个速度很要命，一天才1440分钟，全部导出完成得要差不多俩月时间，这还是在速度恒定的情况下，可事实是随着数据导出的进展，导出速度会越来越慢。经过不断的开发方法的改进，包括技术开发方案的调整，最终我们将导出的速度优化为每次生成2000条数据的xml文件只需要2秒，这样一天多点我们就可以将一亿条记录的表中的数据都抽取出来了。

再举个简单的例子，某SQL需要提取出blog上文章的前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，性能自然而然也就提高了。当然，在用户量和访问量进一步提高的时候，就得采取其他的方法了，比如加缓存之类的，这是另外的话题，就不细说了。

另外还有个例子是09年我做过一个项目，当时我们和别的公司都需要往数据库里导入300G的数据，我当时采取了多进程的方式导入，结果最快的一次不到7小时就全部导入完成了，而另外那公司5天了还没导完，服务器配置双方都差不多，怎么时间差这么多？一问，他们采用单进程的方式。这本不是什么高深的技术，但知道和不知道的成本有时候就会相差很多。（

http://www.itpub.net/thread-1138531-1-1.html ）

arron刘：
平时了解到大部分的DBA都在忙于救火，启停数据库、调整数据库参数、SQL调优、备份恢复等工作是家常便饭，整天忙于这些技术要求虽然不低但又重复性很高的工作。那么您认为技术进步对DBA职业发展会有怎样的影响？
lastwinner：
有人认为技术进步，DBA要失业了，其实完全不是这样的，如果真的失业，那只有一个原因——就是你落伍了。“活到老就要学到老，学到老才能活到老"

“历史总是惊人的相似”，这话放在这里说也是非常合适的。农业集约化生产、制造企业生产线上出现机器人等，无一不是将某些重复性的操作交由机器去执行，这毫无疑问压缩了从业者的生存空间，但从另一方面讲却对从业者却提出了更高的要求，农场主必须拥有大规模种植的管理能力，而生产线上必然要有人能掌控机器人或者具有机器人不具备的能力，而不具备这些能力的人必将被淘汰出局。

技术进步只会减少重复性的劳动，而且多数还是“体力”劳动。数据库方面的技术进步，将让DBA们更加专注于业务方面的考量，发挥出DBA本身应有的更大的价值，但同时也对DBA提出了更高的要求。以前你擅长的工作现在可以轻易被新技术所取代，那你就必须学会新的本领，现实其实是很残酷的，尽管我们处于文明社会中，“弱肉强食”的丛林法则照样适用。

诚然，机遇总是和挑战并行的，敞开心扉，纳入新知，新时代的“弄潮屌丝”非你莫属！要知道，技术进步也会促进新职位的出现，因为技术进步会促进产业分工明晰，这时候DBA必然会分化到各个不同的细分领域，比如“产品DBA”、“调优DBA”、“应用开发DBA”等。综合上面所讲的，我认为，“应用开发DBA”的群体会越来越壮大，因为这部分群体有强烈的市场需求。而作为常规意义上的DBA，多掌握一些开发技术，会让你的数据库管理更加游刃有余，轻松许多！尤其更能应对将来的职业挑战。

啥？“lastwinner”是“最终的赢家”的意思么？呵呵，还有人对我的id感兴趣呀，那我简单说一下，last除了具有“最后的”含义，还可以作为动词“坚持”去使用，所以我取这个id的真正含义是“只有坚持才能成为最终的胜利者！”——To last long to be the last winner! 这句话也送给大家，祝愿大家都能在开发岗位上通过坚持不懈取得更好更优的成绩！

arron刘：活到老就要学到老，学到老才能活到老,怀大师说的好，一句很简单的话，说出了一个技术人员能在行业中永不落后的秘诀！谢谢您的精彩内容分享。

嘉宾介绍：

姓名：怀晓明
社区ID：lastwinner个人简介：曾获得第一届ITPUB最佳建议奖，并在多个大型IT企业多年的工作历练中，积累了丰富的系统架构设计经验，擅长数据库和Web的设计、开发，精于故障诊断与处理，具有丰富的省部级电子政务行业工作经验及项目管理经验。合著作品有《剑破冰山——ORACLE开发艺术》、《Oracle DBA手记2》。

往期节目回顾：ITPUB社区全新打造新栏目——《ITPUB名人堂》

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/26692020/viewspace-3155049/ ，如需转载，请注明出处，否则将追究法律责任。