SQL应用重构
基本信息
- 原书名: Refactoring SQL Applications
- 原出版社: O'Reilly Media
- 作者: Stephane Faroult Pascal L'Hermite [作译者介绍]
- 译者: 苏敬凯
- 丛书名: 北京华章图文信息有限公司O'Reilly系列
- 出版社:机械工业出版社
- ISBN:9787111263586
- 上架时间:2009-11-19
- 出版日期:2010 年1月
- 开本:16开
- 页码:286
- 版次:1-1
- 所属分类:
计算机 > 数据库 > SQL语言
编辑推荐
“终于有了这样一本书,它强调TSQL编写者在数据库总体性能上的作用,以及怎么来改进这一情形。对于任何一位数据库专业人士来说,只要你想要提升自己的查询编写能力,或者想要改进别人写的查询,那么本书就是你的必读之书。”
——Dwayne King,总裁,KRIDAN Consulting
内容简介回到顶部↑
当数据库的性能达不到预期时,该怎么办呢?在用昂贵的硬件升级的力、法来解决这一问题之前,请拿起这本书。本书将教你如何发现和评估需要重构的代码,理解重构和性能之间至关重要的关系。如果你的应用陷入了困境,那么本书将能帮你使它重新加快速度。.
在本书中你将学习到:..
·判断你是否(以及在哪里)可以得到性能的提升。
·应用快速修复的方法,例如在存储函数和过程中限制对数据库的调用。
·改写sql语句以提高数据访问的效率。
·重构任务,例如用存储过程代替应用代码,用全面的sql语句代替重复的过程化语句。
·增加并行以重构流程。
·使用模式扩展、常规视图、物化视图、分区等来重构设计。...
在本书中你将学习到:..
·判断你是否(以及在哪里)可以得到性能的提升。
·应用快速修复的方法,例如在存储函数和过程中限制对数据库的调用。
·改写sql语句以提高数据访问的效率。
·重构任务,例如用存储过程代替应用代码,用全面的sql语句代替重复的过程化语句。
·增加并行以重构流程。
·使用模式扩展、常规视图、物化视图、分区等来重构设计。...
作译者回到顶部↑
本书提供作译者介绍
Stephane Faroult从1983年开始接触关系数据库和SQL语言,他从事数据库咨询工作已经20多年了。O'Reilly的《The Art of SQL》也是他的作品。...
.. << 查看详细
.. << 查看详细
目录回到顶部↑
前言.
第1章 评估
一个简单的例子
评估可能的收益
第2章 健全检查
统计信息与数据失真
检查索引
解析与绑定变量
大数据量操作
事务管理
第3章 用户函数和视图
用户自定义函数
视图
第4章 测试框架
生成测试数据
比较备选版本
第5章 语句重构
执行计划和优化器指示..
分析缓慢查询
重构查询核心
第1章 评估
一个简单的例子
评估可能的收益
第2章 健全检查
统计信息与数据失真
检查索引
解析与绑定变量
大数据量操作
事务管理
第3章 用户函数和视图
用户自定义函数
视图
第4章 测试框架
生成测试数据
比较备选版本
第5章 语句重构
执行计划和优化器指示..
分析缓慢查询
重构查询核心
译者序回到顶部↑
在翻译本书时,正流行着几本名为“啥啥之美”的书。本书也可以说讲的就是“如何将SQL写得更美”。.
SQL之美就在于用清楚合理的方式告诉DBMS你要做什么,让DBMS总能以最优的方式高效地完成任务。SQL是一种描述式语言,在描述中要表达清楚能够影响优化器决策的要点,同时避免过程化思维的那些细节。而要做到这一点,理解优化器的工作方式和SQL的理念至关重要,正如某条广告语讲的那样“知其道,用其妙”。..
本书作者从事数据库咨询工作多年,在本书中,不仅举出了很多具体生动的例子,还讲述了很多重构SQL应用的思想。无论你是DBA还是程序员,本书都能帮你写出或改写(也就是重构)出优美的SQL语句、清楚明了的处理过程,从而交付出高效的系统,赢得众人的赞许,就像书中的很多故事那样。
参加本书翻译的还有赵龙刚、金振林、周志强、杨宁等。本书翻译力求忠于原著,但由于时间仓促,译者水平有限,翻译错误和不妥之处在所难免,欢迎广大读者批评指正。
苏敬凯
2008年12月...
SQL之美就在于用清楚合理的方式告诉DBMS你要做什么,让DBMS总能以最优的方式高效地完成任务。SQL是一种描述式语言,在描述中要表达清楚能够影响优化器决策的要点,同时避免过程化思维的那些细节。而要做到这一点,理解优化器的工作方式和SQL的理念至关重要,正如某条广告语讲的那样“知其道,用其妙”。..
本书作者从事数据库咨询工作多年,在本书中,不仅举出了很多具体生动的例子,还讲述了很多重构SQL应用的思想。无论你是DBA还是程序员,本书都能帮你写出或改写(也就是重构)出优美的SQL语句、清楚明了的处理过程,从而交付出高效的系统,赢得众人的赞许,就像书中的很多故事那样。
参加本书翻译的还有赵龙刚、金振林、周志强、杨宁等。本书翻译力求忠于原著,但由于时间仓促,译者水平有限,翻译错误和不妥之处在所难免,欢迎广大读者批评指正。
苏敬凯
2008年12月...
前言回到顶部↑
我写书的目的是让它对于能理解它的人有用,因此,我更应当去探究问题的真相,而不是想当然。.
——尼可罗·马基亚维利
《君主论》第15章
在本书的背后有一个故事。那时我刚刚写完《The Art of SQL》,该书还没有开始销售,该书的编辑Jonathan Gennick就产生了让我写一本关于SQL重构的书的想法。我知道SQL,但从未听过SQL重构。于是,我Google了一下这个词,在莫里哀的名剧《贵人迷》中,茹尔丹先生(Monsieur Jourdain),一位富有但没受过良好教育的男子,在他成年以后才开始上一些课程,他惊讶地发现原来他一辈子一直都在说“散文”。就像茹尔丹先生那样,我发现多年来我一直在重构SQL代码,却不知道这个词——对客户的系统进行性能分析会非常自然地引发“通过增量的小改动来改进代码同时又不改变程序”的行为。重构SQL应用就是:尽你所能设计出一个好数据库来,并对架构和程序进行合理布局以使对数据库的访问更加高效。另一个问题就是:你所面对的系统未必是一个刚开始设计的系统,它可能已经运行了若干年,一切都已超出了控制而你却还必须要使用它,那么如何能使这些系统的性能达到最佳呢。以这样一个在我的职业生涯中经常出现的视角来展现SQL语言,这种想法确实有些吸引力。
在写完一本书之后,最不想做的事情就是再写另一本书。但这个想法却一下子抓住了我的心。我曾和几个朋友讨论过这一想法,其中一个人是我所认识的最令人敬畏的SQL专家。这个朋友爆发了,这些时髦词汇使他义愤填膺。不过,这一次我不能同意他的意见了。确实,这一首先由Martin Fowle,(注1)普及开来的“通过小得几乎微不足道的局部修改来改进代码”的想法看起来就像一种时尚——完全是由那些刚刚从大学毕业的企业顾问们用报告堆积出来的时尚。但对于我来说,重构的真正意义不仅在于“我们不再把那些已投入生产的代码视作是神圣不可侵犯的”,还在于我们认识到“只要经过一点努力,很多表现平庸的系统就能够表现得好很多”。重构还是一种认可,承认“性能不令人满意的错误在于我们自己,而不在于我们的运气”,这也确实是业界的一个启示。
在很多地方我都看到,IT经理们对于性能有着一种几乎悲观的态度,人们感觉是受着命运的折磨,他们把最后的一点希望放在“调优”上。如果数据库和系统管理员的努力失败了,在他们看来,唯一的选择就只能是签发订单采购性能更高的硬件了。我也读到过很多自称是数据库专家的人所写的审计报告,在将系统工具的输出重新编排了一下格式之后,他们就得出了“需要提高某几个参数”以及“应该增加更多内存”的结论。公平地说,有些报告中也提到了应该对一些糟糕的查询进行“调优”,但除了把SQL语句的执行计划贴在附录里之外,没有更明确地说明如何调优。
我已经很多年没有碰过数据库的参数了(客户的技术团队通常很称职)。不过,我改进了很多程序,毫无畏惧地研究它们,我尽可能和开发人员一起工作,而不是呆在我的象牙塔里从很远的地方发号施令。我几乎总是遇到渴望学习和理解的人、几乎不需要鼓励就能走上正确道路的人、喜欢学习SQL技能的人以及能很快开始为自己设定性能目标的人。
当流逝的时光将写书的痛苦从我的记忆中抹去之后,我做出了果断的决定,又一次开始了写作,因为我打算扩展这些在我与开发人员一起工作时想要传达给他们的思想。数据库访问可能是能从代码改进中获益最多的区域之一。我写本书的目的不是给出一些具体的做法,而是给出一个框架,以此来改进我们周围那些不够理想的SQL应用,而不用从头开始重写它们(尽管有时重写会有非常强的诱惑力)。
为什么重构
大多数的应用迟早都会遇到性能问题。最好的情况是,一些辉煌的应用系统曾经是成功的,随着时间的推移,它们要处理的数据量已达到了设计时根本想不到的程度。因此,这些旧程序需要重生,直到在生产环境中投入了一个新的应用系统来替代它为止。最坏的情况是,在产品上线之前所进行的性能测试中,就发现性能不能满足服务水平要求。而介乎于最好与最坏之间的情况是,数据量增长、增加新功能、软件升级或配置变更都时常能揭示出一些一直隐藏着的瑕疵,而又不是永远都可以选择回溯。所有这些情况都有极其苛刻的性能改进截止期限和很高的压力。
首先到达的救援队通常都是系统工程师和数据库管理员,他们被请来表演神奇的参数舞蹈。除非之前没有注意到某些非常大的错误(这确实发生过),对于系统性能的提升来说,数据库和系统调优的帮助通常很有限。
这时,下一步的传统做法一直就是:为应用系统中投入更多的硬件。这是一个成本非常高的选择,因为硬件的价格中可能还包含了更高的软件许可成本。这样做还会中断业务的运行,并且必须为此制订计划。令人担忧的是,无法真正保证这一投资能有所回报。很多大型硬件升级后都没有达到预期效果,这种情况不止一次地发生过。似乎与我们的直觉相反,很多大型硬件升级的恐怖故事实际上是:硬件升级反而导致了性能的退化。在很多情况下,在一台机器里多加几个处理器也只不过是进一步加剧了进程之间的争夺而已。
重构的概念引入了一个在调优和大型硬件投入之间的急需的中间状态。在Martin Fowler的那部关于重构的有创意的著作中,他所关注的是面向对象技术。但是数据库所处的情景与用对象语言或过程语言编写的应用程序有着明显的差异,而这些差异也带来了一些对于重构工作的特殊的曲解。例如:
小改动有时不那么小
由于SQL语言的描述式的本质,对于代码的小改动往往给在SQL引擎中的执行带来巨大的影响,这也就会导致性能上的巨大变化——可能更好也可能更差。
对改动的有效性进行测试可能校园难
检查返回一个值的函数非常简单,只要检查在各种情况下代码修改前后的返向值是否相同就行了。而在改写了一个主要的update语句后,要检查一个大表的内容是否保持相同,这完全是另外一回事。
上下文环境往往是决定性的
在问题出现前的若干年里,数据库应用系统可能一直运行得非常令人满意:但在数据量或负载超过了某些阈值之后,或者在一次软件升级改变了优化器的行为之后,性能往往会突然变得无法让人接受。对于数据库应用系统的性能改进工作通常就发生在一场危机当中。
因此,数据库应用系统是重构的一个完全不同的战场,而同时这种努力也可能是(往往也就是)有高额回报的。
——尼可罗·马基亚维利
《君主论》第15章
在本书的背后有一个故事。那时我刚刚写完《The Art of SQL》,该书还没有开始销售,该书的编辑Jonathan Gennick就产生了让我写一本关于SQL重构的书的想法。我知道SQL,但从未听过SQL重构。于是,我Google了一下这个词,在莫里哀的名剧《贵人迷》中,茹尔丹先生(Monsieur Jourdain),一位富有但没受过良好教育的男子,在他成年以后才开始上一些课程,他惊讶地发现原来他一辈子一直都在说“散文”。就像茹尔丹先生那样,我发现多年来我一直在重构SQL代码,却不知道这个词——对客户的系统进行性能分析会非常自然地引发“通过增量的小改动来改进代码同时又不改变程序”的行为。重构SQL应用就是:尽你所能设计出一个好数据库来,并对架构和程序进行合理布局以使对数据库的访问更加高效。另一个问题就是:你所面对的系统未必是一个刚开始设计的系统,它可能已经运行了若干年,一切都已超出了控制而你却还必须要使用它,那么如何能使这些系统的性能达到最佳呢。以这样一个在我的职业生涯中经常出现的视角来展现SQL语言,这种想法确实有些吸引力。
在写完一本书之后,最不想做的事情就是再写另一本书。但这个想法却一下子抓住了我的心。我曾和几个朋友讨论过这一想法,其中一个人是我所认识的最令人敬畏的SQL专家。这个朋友爆发了,这些时髦词汇使他义愤填膺。不过,这一次我不能同意他的意见了。确实,这一首先由Martin Fowle,(注1)普及开来的“通过小得几乎微不足道的局部修改来改进代码”的想法看起来就像一种时尚——完全是由那些刚刚从大学毕业的企业顾问们用报告堆积出来的时尚。但对于我来说,重构的真正意义不仅在于“我们不再把那些已投入生产的代码视作是神圣不可侵犯的”,还在于我们认识到“只要经过一点努力,很多表现平庸的系统就能够表现得好很多”。重构还是一种认可,承认“性能不令人满意的错误在于我们自己,而不在于我们的运气”,这也确实是业界的一个启示。
在很多地方我都看到,IT经理们对于性能有着一种几乎悲观的态度,人们感觉是受着命运的折磨,他们把最后的一点希望放在“调优”上。如果数据库和系统管理员的努力失败了,在他们看来,唯一的选择就只能是签发订单采购性能更高的硬件了。我也读到过很多自称是数据库专家的人所写的审计报告,在将系统工具的输出重新编排了一下格式之后,他们就得出了“需要提高某几个参数”以及“应该增加更多内存”的结论。公平地说,有些报告中也提到了应该对一些糟糕的查询进行“调优”,但除了把SQL语句的执行计划贴在附录里之外,没有更明确地说明如何调优。
我已经很多年没有碰过数据库的参数了(客户的技术团队通常很称职)。不过,我改进了很多程序,毫无畏惧地研究它们,我尽可能和开发人员一起工作,而不是呆在我的象牙塔里从很远的地方发号施令。我几乎总是遇到渴望学习和理解的人、几乎不需要鼓励就能走上正确道路的人、喜欢学习SQL技能的人以及能很快开始为自己设定性能目标的人。
当流逝的时光将写书的痛苦从我的记忆中抹去之后,我做出了果断的决定,又一次开始了写作,因为我打算扩展这些在我与开发人员一起工作时想要传达给他们的思想。数据库访问可能是能从代码改进中获益最多的区域之一。我写本书的目的不是给出一些具体的做法,而是给出一个框架,以此来改进我们周围那些不够理想的SQL应用,而不用从头开始重写它们(尽管有时重写会有非常强的诱惑力)。
为什么重构
大多数的应用迟早都会遇到性能问题。最好的情况是,一些辉煌的应用系统曾经是成功的,随着时间的推移,它们要处理的数据量已达到了设计时根本想不到的程度。因此,这些旧程序需要重生,直到在生产环境中投入了一个新的应用系统来替代它为止。最坏的情况是,在产品上线之前所进行的性能测试中,就发现性能不能满足服务水平要求。而介乎于最好与最坏之间的情况是,数据量增长、增加新功能、软件升级或配置变更都时常能揭示出一些一直隐藏着的瑕疵,而又不是永远都可以选择回溯。所有这些情况都有极其苛刻的性能改进截止期限和很高的压力。
首先到达的救援队通常都是系统工程师和数据库管理员,他们被请来表演神奇的参数舞蹈。除非之前没有注意到某些非常大的错误(这确实发生过),对于系统性能的提升来说,数据库和系统调优的帮助通常很有限。
这时,下一步的传统做法一直就是:为应用系统中投入更多的硬件。这是一个成本非常高的选择,因为硬件的价格中可能还包含了更高的软件许可成本。这样做还会中断业务的运行,并且必须为此制订计划。令人担忧的是,无法真正保证这一投资能有所回报。很多大型硬件升级后都没有达到预期效果,这种情况不止一次地发生过。似乎与我们的直觉相反,很多大型硬件升级的恐怖故事实际上是:硬件升级反而导致了性能的退化。在很多情况下,在一台机器里多加几个处理器也只不过是进一步加剧了进程之间的争夺而已。
重构的概念引入了一个在调优和大型硬件投入之间的急需的中间状态。在Martin Fowler的那部关于重构的有创意的著作中,他所关注的是面向对象技术。但是数据库所处的情景与用对象语言或过程语言编写的应用程序有着明显的差异,而这些差异也带来了一些对于重构工作的特殊的曲解。例如:
小改动有时不那么小
由于SQL语言的描述式的本质,对于代码的小改动往往给在SQL引擎中的执行带来巨大的影响,这也就会导致性能上的巨大变化——可能更好也可能更差。
对改动的有效性进行测试可能校园难
检查返回一个值的函数非常简单,只要检查在各种情况下代码修改前后的返向值是否相同就行了。而在改写了一个主要的update语句后,要检查一个大表的内容是否保持相同,这完全是另外一回事。
上下文环境往往是决定性的
在问题出现前的若干年里,数据库应用系统可能一直运行得非常令人满意:但在数据量或负载超过了某些阈值之后,或者在一次软件升级改变了优化器的行为之后,性能往往会突然变得无法让人接受。对于数据库应用系统的性能改进工作通常就发生在一场危机当中。
因此,数据库应用系统是重构的一个完全不同的战场,而同时这种努力也可能是(往往也就是)有高额回报的。
媒体评论回到顶部↑
“有很多讲述程序重构的书,但一直缺少讲述数据库代码重构的书,直到本书出版为止。在Stephane Faroult的这本新书中有很多高级的SQL技术,我一直在自己的工作中使用这些技术。我热情地向大家推荐这本书。”.
——Michael Blaha,咨询师,OMT Associates Inc.
“终于有了这样一本书,它强调TSQL编写者在数据库总体性能上的作用,以及怎么来改进这一情形。对于任何一位数据库专业人士来说,只要你想要提升自己的查询编写能力,或者想要改进别人写的查询,那么本书就是你的必读之书。”..
——Dwayne King,总裁,KRIDAN Consulting
“本书装满了宝贝。在放下本书之前,你一定会体验到惊喜。在本书中,Faroult先生慷慨地分享了他的那些丰富的经历和清晰的思维。”
——Roy Owens,数据库开发人员,CBORD Group,Inc....
——Michael Blaha,咨询师,OMT Associates Inc.
“终于有了这样一本书,它强调TSQL编写者在数据库总体性能上的作用,以及怎么来改进这一情形。对于任何一位数据库专业人士来说,只要你想要提升自己的查询编写能力,或者想要改进别人写的查询,那么本书就是你的必读之书。”..
——Dwayne King,总裁,KRIDAN Consulting
“本书装满了宝贝。在放下本书之前,你一定会体验到惊喜。在本书中,Faroult先生慷慨地分享了他的那些丰富的经历和清晰的思维。”
——Roy Owens,数据库开发人员,CBORD Group,Inc....
评论交流
共有17人开贴评论 17人参与评论 14人参与打分 查看
评价等级:







发表于:2010-3-5 0:27:00
最近半年互动出版社活动做得相当不错,让我这个当当和卓越的客户投奔“互动”而来,一口气了下了500多米的单。第一次在互动写书评,稍显不习惯。
把我“互动”的第一次评论献给了《SQL应用重构》,算是实至名归吧。在我的理念中,一本书如果有一个章节闪光,就值得付出相应的金钱换取这些闪光点的价值。而这本书,硬是吸引着我连续几天下班后奔向公司旁的图书城直立数小时去反复阅读某些章节,于是乎在阅读了大半章节后终于买于囊中。
该书译文基本上不妨碍阅读和理解,有了相应的SQL基本知识,具有某种OO语言的编程经验,书中Code读来颇为美感,呵呵。做和高明之处从“一个简单的例子”开篇,看似简单,却让吾等愚昧之辈通读两遍以上,一个简单的例子中却蕴含了许许多多不那么平常的实践真知。我工作的数据库产品是MS SQL2000/2005,对MySQL有一些基本认识,从未涉猎过Oracle产品。在阅读第一章“评估”时,作者对于“索引”的表现出来的认同观给了我一种亲近感——“索引”不是不重要,是非常重要,但是却不是最重要的。往往向我这样从互联网应用程序开发作为IT职业起点的软件工程师,对于索引的依赖是超乎想象的,将索引视为救命稻草和拯救性能的万能药,长时间的倦怠中,忽略了对应用程序本身性能的提升,也懒于对SQL做更深层次的了解。事实总是残酷的,当你迫于棘手的问题无法解决压力,面对那些糟糕的数据库设计,纵使你最爱的索引也无法拯救你时,重构在所难免,哪怕你在不情愿。你能做的或许就是学习更多、了解更多,强迫自己推到当初的无知,修正自己的无知。
作者第五章关于“语句重构”也颇为吸引人,只有经历过章节描述某些过程的你,才能真切体会。一个你认为调优到极点的SQL语句,往往真的存在进一步的空间。正如我自己,在MSSQL中,对于执行计划的依赖是很大,往往一个SQL语句是否最优,大部分时候都仅凭执行计划的对比优劣来决定。可随着生产环境中数据发生不断变化,量变的积累使得某些曾经最优的发生了“质变”——最优的语句们都变质了。作者在第五章中透露的观点:一个具有美感,条理清晰的SQL语句真的如同写文章一般,想让优化器能够更真实的命中执行路径,确实需要正确认识SQL,透彻了解SQL这么语言,才能写出具有条理又不失美感的语句来。
第六章作者透露的另一个观点:在当前的现实生活中,对某一条SQL语句的调优不再像若干年前那么至关重要了。我们日益需要的不再只是精通那些对现有语句改进的SQL技能,而更需要精通那些通过非常少的数据库访问就能完成任务的技巧。这个观点也足以引起我的共鸣,深有体会。在我的工作中,切合于这个观点字面上理解的做法,如我曾经做过将多达几十条,少则几条调优之后的SQL语句,封装成一个过程,或者将过程集合之后再做一次封装,然后读取一次数据库返回N个结果集,对应于ADO.NET中一个数据记录集对象,这种尝试带来的收益是客观的,也是非常有效的。不行你也尝试下?呵呵。
好了,噼里啪啦的写了这么多,都是我自己关于这本的认同和认知,这个世界上没有绝对的好,当你处于某一个阶段的时候,总有些东西会和你产生共鸣,而此时这些东西就是好的,是有益的,如同《SQL应用重构》这本书于此刻的我一般。希望大家不要建议这么长篇罗嗦的随感,呵呵。
把我“互动”的第一次评论献给了《SQL应用重构》,算是实至名归吧。在我的理念中,一本书如果有一个章节闪光,就值得付出相应的金钱换取这些闪光点的价值。而这本书,硬是吸引着我连续几天下班后奔向公司旁的图书城直立数小时去反复阅读某些章节,于是乎在阅读了大半章节后终于买于囊中。
该书译文基本上不妨碍阅读和理解,有了相应的SQL基本知识,具有某种OO语言的编程经验,书中Code读来颇为美感,呵呵。做和高明之处从“一个简单的例子”开篇,看似简单,却让吾等愚昧之辈通读两遍以上,一个简单的例子中却蕴含了许许多多不那么平常的实践真知。我工作的数据库产品是MS SQL2000/2005,对MySQL有一些基本认识,从未涉猎过Oracle产品。在阅读第一章“评估”时,作者对于“索引”的表现出来的认同观给了我一种亲近感——“索引”不是不重要,是非常重要,但是却不是最重要的。往往向我这样从互联网应用程序开发作为IT职业起点的软件工程师,对于索引的依赖是超乎想象的,将索引视为救命稻草和拯救性能的万能药,长时间的倦怠中,忽略了对应用程序本身性能的提升,也懒于对SQL做更深层次的了解。事实总是残酷的,当你迫于棘手的问题无法解决压力,面对那些糟糕的数据库设计,纵使你最爱的索引也无法拯救你时,重构在所难免,哪怕你在不情愿。你能做的或许就是学习更多、了解更多,强迫自己推到当初的无知,修正自己的无知。
作者第五章关于“语句重构”也颇为吸引人,只有经历过章节描述某些过程的你,才能真切体会。一个你认为调优到极点的SQL语句,往往真的存在进一步的空间。正如我自己,在MSSQL中,对于执行计划的依赖是很大,往往一个SQL语句是否最优,大部分时候都仅凭执行计划的对比优劣来决定。可随着生产环境中数据发生不断变化,量变的积累使得某些曾经最优的发生了“质变”——最优的语句们都变质了。作者在第五章中透露的观点:一个具有美感,条理清晰的SQL语句真的如同写文章一般,想让优化器能够更真实的命中执行路径,确实需要正确认识SQL,透彻了解SQL这么语言,才能写出具有条理又不失美感的语句来。
第六章作者透露的另一个观点:在当前的现实生活中,对某一条SQL语句的调优不再像若干年前那么至关重要了。我们日益需要的不再只是精通那些对现有语句改进的SQL技能,而更需要精通那些通过非常少的数据库访问就能完成任务的技巧。这个观点也足以引起我的共鸣,深有体会。在我的工作中,切合于这个观点字面上理解的做法,如我曾经做过将多达几十条,少则几条调优之后的SQL语句,封装成一个过程,或者将过程集合之后再做一次封装,然后读取一次数据库返回N个结果集,对应于ADO.NET中一个数据记录集对象,这种尝试带来的收益是客观的,也是非常有效的。不行你也尝试下?呵呵。
好了,噼里啪啦的写了这么多,都是我自己关于这本的认同和认知,这个世界上没有绝对的好,当你处于某一个阶段的时候,总有些东西会和你产生共鸣,而此时这些东西就是好的,是有益的,如同《SQL应用重构》这本书于此刻的我一般。希望大家不要建议这么长篇罗嗦的随感,呵呵。
| 我要写评论 |
| 查看所有评论交流(共17条) |


点击看大图




加载中...
