2000W条数据的Oralce数据库SQL查询优化经验- 机会总会留给有准备的人 ...

  无论你写了什么、做了什么、别人都觉得你没啥的、写得不好、不深入,给你泼N多冷水,但是往往这些泼冷水的家伙往往大多是狗屁不是的家伙,甚至大多是马甲而已,有本事大家都多写写文章,用文章、用实力来证明写得更好就足可以让大家心服口服了。

 

  我为了鼓励其他同行写文章,几乎觉得写得不错的文章,都给推荐+1,这是无形的支持与鼓励,举手之劳而已,但是能给人很多鼓舞了,先讲购买他的软件产品,至少点一下推荐+1,又不花费力气,也不用花钱,的确从他的文章里学到了知识、自己也提高了,那就顺手点一下推荐+1,难道就想要个这么简单的回报,都那么难?搞软件开发的都吝啬小气到这个程度了?

 

正文部分

============================================================================================ 

  1:今年公司里有一些人辞职了,他们大多都觉得在公司没有发挥潜能的机会、没被公司重视、没给足够高的薪水或者其它单位有更高的薪水。

  2:公司有一个2000W条数据的Oralce查询功能,运行速度有些缓慢,但是一直没人能有效解决这个问题,或者对此没啥兴趣爱好。

  3:有一部分人觉得,自己不是干数据库技术的,有些人觉得这个事情不管他的事情,有些人觉得这个没办法解决,但是客户的反应有些强烈。

  4:这个事情也变成了老板、项目经理、客户经理的一块心病,甚至影响了整个项目的验收及收款,我们只能迎难而上。

 

  当老板把这个任务压到我们开发部头上时,我们逃也逃不掉,虽然我们平时是写C#程序为主,但是数据库性能优化也只能由我们自己做:

  当时觉得需要2周时间有希望能解决,1周熟悉业务及数据结构,另1周用来性能优化,我也是新来的,对项目不熟悉、功能也不熟悉,所以觉得需要2周时间也是天经地义的,但是老板说必须要解决这个问题而且只能给1周时间。

  没办法的事情老板的命令下来了只能执行,要们就丢这个饭碗,我就跟我们公司的一个搭档承担了这个攻坚任务。

 

  曾经很多年前,优化过别人的MYSQL的数据库查询优化,当时公司里有个牛B轰轰的程序员,觉得自己的数学水平高、编写程序思路也很严,平时谁也不服,也不把别人放在眼里的那种,当他有一个数据量很大的程序运行效率比较低时,老板让我看看是否能提高性能,我足足用了半个小时,优化了他的SQL语句,结果性能提高了10倍,只用了1/10的运行时间就可以了,这次成功的SQL优化,给了我很大的信心,而且开始对性能优化有了很高的兴趣。

  后来几年里看了很多数据库方面的资料,但是一直没遇到过能发挥实力的机会,也学了很多数据库脚本编成,但是一直没机会能露两手,不过自己一直是对数据库优化很有信心了,平时也很自信。

 

  但是最近几年,心思没在数据库优化上了,大多是用在“大规模编程系统架构优化”上,而且Oralce没有用也有好几年了,开始也不敢吹了,毕竟不是天天干这个的,时代发展得也快,新技术都没留意过了。

  自己没信心了,那就先找找这方面的专家,看看人家有没有什么好的建议吧,我和我的搭档就开始这个痛苦的数据库优化工作了。

  01:先找集团内部的资源,找名气比较大的专业的数据库管理员,给了我们一些建议系统底层优化的建议,对我们没实质性的进展,失败。

  02:只能硬着头皮与同事们一起深入研究,发现SQL语句也很复杂,并没有想象的那么简单。

  03:把比较复杂的SQL语句先分解成若干个简单的SQL语句,运行、失望,性能影响不大,失败。

  05:里面有些多余的字段被SELECT出来的字段,去掉了,没有明显的进展,影响不大,失败。

  06:SELECT 出来的东西,再进行了SUM操作,感觉内存里的处理数据过大,先进行SUM,再进行SELECT,没有明显的进展,影响不大,失败。

  07:把2000W条数据的表,拆开成若干个表,每个表达该500W条数据,没有明显的进展,影响不大,失败。

  08:修改数据类型,把数值类型的长度、精度在变小点儿,影响不大,失败。

  09:数值类型比较,例如日期类型的比较,不要转成字符再比较,人家已经这么做了,没这方面的缺陷。

  11:查询条件的先后顺序调整,影响不大,失败。

  12:将过滤条件放到子语句里,选出来的数据尽量小一些,影响不大,失败。

  13:再看看索引,以前的开发人员索引设置得也比较合理,而且他们告诉我们,他们做测试优化索引,耗时会更多,去掉索引反而还会好一些。

  14:经过这8个步骤,我是有些失望了、心情沉重,但是我不能把这个表现出现,还是继续表现得很自信,不管遇到什么困难,都需要给自己打气、给自己信心,男人要坚强、只能靠自己了。

  15:接下来足足想了一晚上,问题会出在哪里?数据库的极限能力是多少?找谁咨询?2000W条数据不应该是Oracle的性能瓶颈呀,问题应该是我们身上。

  16:继续坚信问题应该是在设置索引上,继续把重点突破口放在深入索引设置上,按不同的组合、不同的索引方式进行优化。

  17:索引优化后,奇迹出现了,性能提高了100倍,唉,这下不用丢饭碗了谢天谢地了,问题搞定了,可以给老板一个交待了,老天不想灭我们2个呀。

  18:不管是干啥,都需要靠自己,不要指望靠别人能解决问题,关键时刻,一定要对自己时刻打气、始终需要保持必胜的信念。

 

  2000W条数据的性能优化,我跟搭档一起努力做到了,下一次目标是2亿条数据的性能优化瓶颈了,还是照样需要有信心的

  去年做的是百万元RMB级别的信息管理系统,今年开始在做千万元RMB级别的信息管理系统,将来会是亿元RMB级别的信息管理系统了,还是照样需要有信心的

 

  每天、每年都在挑战自己能力的极限,每年身心都会死三回,每次挺过来了都会升华三回,需要记住职场不同情弱者。 

 

  想要当个过硬的技术主管不仅需要有“心灵鸡汤”、还需要拿实力证明的,老板不需要“心灵鸡汤”

 

  以下是千万级Oracle数据库性能优化的前后对比表,Oracle为什么那么值钱,唉、不服不行啊、这就叫科学技术,哪{yt}我若能做到了就是死也愿意了。

  

 

   每个软件公司都有很多问题在困扰着老板、客户,只有能及时解决这些棘手问题的人,才是公司最需要的人才,很可能机会就摆在你眼前,其实你也可以的。

 

 

  

 

 

 

posted on 2010-05-01 22:17 阅读(2250)  

评论

就来个这样的回复,会让人看得心服口服,我都从心底很佩服,这才叫有水平的回复啊,再看看上面的那几个回复,这是哪里到哪里啊?虽然这个回复也没告诉我,如何做分区,至少我知道有这么一回事情了,接着就知道自己怎么再深入优化了,下一步应该怎么走了,其他我自己搞定就可以了,要么就付钱咨询人家怎么优化了,他若不收钱那是再好不过的事情了,天上掉馅饼了不是。


NineFlowers:呵呵,数据库工具里都能看到哪些是长时间执行语句,可以通过分析这些语句L语句执行计划,执行计划对每一步的执行消耗表明的很清楚,那步耗时多少,你再找问题所在,这是最基本的方法,通过执行计划我们会知道查询是否使用的索引,为什么绕过了索引而执行了全表扫描了等等,sql语句里条件的顺序等都会造成执行计划的路径不同,这是一般优化的{dy}步,然后你可以对长时间没有整理的表执行表分析,对单表数据量很大,例如几亿条,你首先必须做到事情按照某字段进行表分区,例如按时间分区等等,还有索引的类型等等都会影响。

索引写过查询的都会想到,你不是要走了吗?为啥看了你文章就想给你留言呢
吉日嘎拉 不仅权限设计
对于数据库的优化方法理论,是不分平台的。不论是oracle还是sql server ,优化的方法步骤和理论是相同的,尽管在实现的具体细节中可能会有稍许不同。

对于数据库优化的方法论,已经有前人总结出一套了,推荐你看三部分内容:
1. SQL SERVER 2000 技术内幕,《查询处理器》这一章。它会告诉你很多关于查询处理器工作的细节内容。让你对SQL SERVER 引擎收到一个SQL 语句之后,都做了些什么,以及在查询执行的过程中是怎么做的有一个较为全面的理解。

2. SQL SERVER 2005 T-SQL 查询的《优化的方法论》这一小节的内容。它会告诉你怎么查找出数据库中性能有问题的部分及SQL。

3. SQL SERVER 2005 T-SQL 查询的《索引优化的等级》这一部分的内容。它会告诉你各种扫描/查找(也就是如何利用索引)的成本开销的大致情况。以及在各种环境下如何将索引的访问方法优化到{zy}。

而对于你所遇到的,由客户直接反映出"问题所在"的性能问题,我想“ NineFlowers”已经告诉了你按照什么步骤去做优化了。
81

大家都不是神仙,不可能把所有的问题,都能1分钟内解决好,呵呵。
周强

首先,我谢谢你的回复,mssql的性能优化,大家还是很自信的,但是会微软的数据库与折腾Oralce数据库,还是有很大的差别,一个人会熟练的优化微软的数据库,未必能在短时间内就能优化Oralce数据库,但是给的时间足够长,那是90%是应该能搞定的,但是对于{dj1}的数据库优化,我还是不认可的这一点的。

为什么Oralce的数据库优化专家就那么值钱,SQLServer的数据库优化专家相对就不太值钱了,呵呵,很简单的道理就明显的摆在我们眼前的,还是有很大的区别的。

优秀的的Oralce优化专家,不算{dj0}的,大概年薪20万以上的很普遍的吧,但是没怎么听说过优秀的SQLServer优化专家轻松有20万以上的。

优秀的的Oralce优化专家,不算{dj0}的,大概年薪20万以上的很普遍的吧(哪里得出的统计数据?)

但是没怎么听说过优秀的SQLServer优化专家轻松有20万以上的。
(数据库的使用存在一个历史问题,随着SQL SERVER 逐步步入各个大企业的核心业务,得高薪的SQL SERVER 从业者会越来越多,尽管我无法确定当前SQL SERVER 的从业者是不是拿高薪“较不普遍”)
不知道oracle数据库长啥样的飘过
sqlserver 都有成套的管理分析工具,稍微找找,不看资料都能知道,有可能摸索出来,优化起来,相对简单了一些。

但是Oralce,用什么工具?用什么功能?怎么看?看哪里?都很容易是一头雾水的,有时候想顺利连接上数据库,不懂的、没用过的人还需要折腾个半死的,sqlserver 我老婆都可以轻易的连接上服务器的,这就是差别。

周强:难不成ORACLE无法查看执行计划?

吉日嘎拉 不仅权限设计:
@周强

说说都容易,真正做起来,就没那么容易了,呵呵,我们不反对理论派,也不支持理论派。
java语言与C#语言也差不多,但是C#高手,未必能解决java的问题,呵呵,不同的领域。
可能我比较笨吧,当年为了在Oralce里建立一个类似SQLServer的数据库,足足花费了1天,才搞明白是怎么回事,按道理,不用这么折腾的吧,只有动手去做了,才会明白,是两回事情。



你举得“在Oralce里建立一个类似SQLServer的数据库”例子,说明了你知道“Oracle中可以建立类似SQL SERVER 数据库”,这个可以建立就是“理论”。
而对于“足足花费了1天”,只是表表明了其实现上和SQL SERVER 有不同。

回到本文,理论就是“你应该知道通过查询计划去确定问题”
而实现是“在oracle 中通过oracle的方法调出执行计划”

而显然,本文中表明你“不知道通过查询计划去确定问题”

晚了,睡觉了,明天还有事情....
另外还要计算一下IO时间,这个也很重要,比如你一次select 50M数据,那你要算一下这50M从磁盘上读出来需要多少时间,如果你的执行时间和这个时间很接近,那就很难优化了,这说明不是查询的速度(CPU&内存),而是IO的速度限制了,这是可能要考虑怎么把磁盘弄快一点了。呵呵。

@51楼
Oracle很多组件都是单独购买的,而不是类似sql server一样,企业版全部打包。Oracle买了企业版之后,什么Data Mining啊,OLAP啊,Reporting services啊,XML support啊,等等,都是一个一个单独需要另行购买的组件,你到Oracle官方网站上可以看到一大串列表。我想Oracle也未必没有执行计划查看器吧,或许是你们没有购买,呵呵。执行计划查看器是优化数据库最重要的方式,因为可以直观的看到{zh1}数据库是如何的执行一条sql语句。
咱们虽然水平不行,但是有分享精神,勇于写文章的精神,不怕丢人的精神,拿出来大家交流,从中学习提高,认识到自己的不足,勇于面对困难,敢于真人真姓站出来交流三脚猫功夫,就算是对骂、打口水战,也敢于真人真姓骂个痛快,所以那些马甲有勇气也真人真姓的来骂我,我也认为你是条汉子,穿个马甲来骂我,就被我小看了,呵呵。

我是打酱油的:
一直在支持楼主这种钻研精神,这篇又是一次好的体现,加油!
另外,像其他人指出的,把它上升到理论高度,将来就可以举一反三了。

吉日兄文章的高产令人佩服!不过我还是觉得这是一篇“鸡汤”文章,呵呵!

我想多数人可能都和我一样,非常想知道你是如何优化这个索引的?

数据库性能的优化是一门学问,也可以说是经验,索引的优化只是其中之一。

我个人认为,要想真正提高数据库的性能,还是要从数据结构上下功夫,从表的设计上下功夫,从业务逻辑上下功夫。象你举的SELECE与SUM的例子,就是数据表的设计不合理,并不能从索引上做根本的解决。
从治标的角度,这种做法是OK的,如果由此不会引发新的问题(增加索引必然是insert\update时间增加),那是很简单的。

如果有这样一个报表:
每个月的销售占比,估算一下领导看到这个表至少需要:
2*12=24秒,
还是不能满足要求的,要适时使用数据仓库的工具了。

综合来说,还是个软件架构问题,和索引关系不是很大。
(意思是说:现在的做法是治标;因为只有从架构的角度,才能从根上解决和此相关的所有问题)


==》从另外的一个侧面,说明你们公司的DBA,根本不称职,或狗屁不通
(或者没有DBA职位)
吉日嘎拉 不仅权限设计:
@周强

首先,我谢谢你的回复,mssql的性能优化,大家还是很自信的,但是会微软的数据库与折腾Oralce数据库,还是有很大的差别,一个人会熟练的优化微软的数据库,未必能在短时间内就能优化Oralce数据库,但是给的时间足够长,那是90%是应该能搞定的,但是对于{dj1}的数据库优化,我还是不认可的这一点的。

为什么Oralce的数据库优化专家就那么值钱,SQLServer的数据库优化专家相对就不太值钱了,呵呵,很简单的道理就明显的摆在我们眼前的,还是有很大的区别的。

优秀的的Oralce优化专家,不算{dj0}的,大概年薪20万以上的很普遍的吧,但是没怎么听说过优秀的SQLServer优化专家轻松有20万以上的。




Oracle不管{dj0}的轻松上20W以上?你给的?

"没怎么听说过优秀的SQLServer优化专家轻松有20万以上"
这说明你没在这个圈子里而已,现在很多公司在招SQL Server DBA,薪水都能达到15-20k/mon.

不清楚不要紧,不清楚还拿出来说就是你的不对了。。
居然没有专职DBA
吉日大牛兄弟:
很高兴看到你这么优美的标题名称,我也经常碰见上亿级的ORACLE数据库查询计算优化问题(我们是专业开发电力行业软件的,所以数据量特别大).我们知道,ORACLE数据库优化方面的技术很多,除了最常用的索引之外,比如你还可以使用内存表技术等.
但看了你的索引优化之后,"按不同的组合、不同的索引方式进行优化"没看清楚具体怎么优化的方法(或许咋是小菜).依我看来,索引优化的方法也很多,并且索引优化这个"名词性的口号"好象大家都知道.能够给出具体案例吗,呵呵,这样也才有说服力.......
大师,我也不是{wn}的,我希望我这篇文章,能引出很多其他有想法的人的文章,让大家也写写这方面的深入的文章。

马伟:
吉日大牛兄弟:
很高兴看到你这么优美的标题名称,我也经常碰见上亿级的ORACLE数据库查询计算优化问题(我们是专业开发电力行业软件的,所以数据量特别大).我们知道,ORACLE数据库优化方面的技术很多,除了最常用的索引之外,比如你还可以使用内存表技术等.
但看了你的索引优化之后,"按不同的组合、不同的索引方式进行优化"没看清楚具体怎么优化的方法(或许咋是小菜).依我看来,索引优化的方法也很多,并且索引优化这个"名词性的口号"好象大家都知道.能够给出具体案例吗,呵呵,这样也才有说服力.......

热烈欢迎 “卡通一下”初入此道,陷于困惑、迷茫、苦恼的朋友,呵呵。

卡通一下:
引用玄魂:
迷糊了,如果您想写技术的文章,就不要这么多抱怨和啰嗦,
踏踏实实的有什么不好呢,
除了炫耀我没看到其他的东西,有序有精华,但被掩盖了

老吉的文章多数是“心灵的鸡汤”,它是给那些初入此道,陷于困惑、迷茫、苦恼的朋友写的。如果你是一个成手,或是一个有专长的人,那还是不要看为好;或是看完笑笑就行了,不要忿忿不平...。

老实说,我还是挺喜欢看的!

哈哈...

笨笨的考拉熊:
这点上支持吉日。现在的新人啊,把饭都摆到眼前了,还怪你不拿勺喂他。

引用吉日嘎拉 不仅权限设计:
这很可能表明你还嫩一些,相对有水平的、有点儿基础的人,看个文章的大概就明白是什么意思了,呵呵,看来你还需继续提高了再来读这个文章了,不好意思啊,不是我没写出来知识点,是你没能理解而已,不能怪我了。

引用木鱼:我是来学习的....但是没学到东西...



笨笨的考拉熊兄,你的这个观点我就不太同意.我认为"技术"方面的问题一定要精细化,讲清楚,说明白,而不是点到为止.尤其是这类"优化"话题.
就像我现在说VS2010功能很强大,你能够知道它具体在那些方便表现很强大吗?"如果这时候你再来问我具体强大在那些方面,我说你怎么连这么基础的问题还要问啊,那你去学学VS2010具体功能再来问这个问题吧..."
之所以大家喜欢老赵的文章,因为老赵讲问题很清楚很透彻,就像前段时间写的<<数组排序方法的性能比较系列>>,难到你会说这么基础的数组排序问题还需要讲吗.....
呵呵,{zh1}声明,咋不是针对个人,就事论事而已,千万不要引起不愉快...
吉日兄文章的高产令人佩服!不过我还是觉得这是一篇“鸡汤”文章,呵呵!

我想多数人可能都和我一样,非常想知道你是如何优化这个索引的?

数据库性能的优化是一门学问,也可以说是经验,索引的优化只是其中之一。

我个人认为,要想真正提高数据库的性能,还是要从数据结构上下功夫,从表的设计上下功夫,从业务逻辑上下功夫。象你举的SELECE与SUM的例子,就是数据表的设计不合理,并不能从索引上做根本的解决。

----------------------------------------





@卡通一下
貌似*日的文章都能看到你在鼓风吹浪,一直强调什么鸡汤,你提出的问题,他给你解答了么?有人有了疑问,提出来,*日正面回复过么?这就是你所谓的鸡汤?至于你曾经在*日要滚蛋的文章中为其辩护说海洋的文章看不懂什么的,可是至少海洋的文章没那么多废话,很实在,也许只是他写文章的逻辑还没整清楚,所以让人理解起来很难,反观*日的他自认为的技术文章,其实大多数文字都是废话或者就是忽悠人,只有一两句结论才说到正题上,可是又不讲清楚或者给点思路(又不要直接给代码什么的),更不会在回帖中回答相关的技术问题,不知道是故意的(也就说可能要付费什么的)还是他自己都不怎么清楚。你自己可以从头看*日的文章。

如果这就是你所谓的鸡汤,希望你能坚持喝下去。
OC Life:
@卡通一下
貌似*日的文章都能看到你在鼓风吹浪,一直强调什么鸡汤,你提出的问题,他给你解答了么?......
如果这就是你所谓的鸡汤,希望你能坚持喝下去。

我能得到您的关注,很是荣幸;同时也为吉日感到荣幸,这说明你也经常光顾吉日的博客,不是吗?

至于你说我是鼓风吹浪,一直强调什么鸡汤,那是因为我在喝汤之前,一定要鼓起腮帮子吹去浮油,否则喝多了对身体不好。如果非要说我,那就当我是个汤勺吧,就是来和弄鸡汤的,呵呵...

对于吉日,你恨也好、骂也好、怒也好,毕竟你自己的内心还是想来看看热闹,否则你怎么知道吉日的那么多事情呢?

我曾与吉日开玩笑,说看他的文章一定要把文章的推荐数和反对数加在一起算,如果平淡无奇,到是索然无味!你看吉日文章有那么高的阅读数,不也能说明问题吗?

说到海洋,我觉得海洋的写作态度要比吉日严肃,也很是可爱,呵呵!

海洋的文章不便在此评论,还是到海洋的博客上再说吧。

{zh1},我要说的是博客园中的一些文章,是属于“心灵鸡汤”类的,是用来滋润人们心灵的,而不是用来学习技术的。如果这类文章能引起您的共鸣,那说明您的心灵确实需要“鸡汤”;如果引起您的反感,那您还是快快地倒掉...

我自己既不需要“鸡汤”,也不反感,因为我就是一个大汤勺!

哈哈...

卡通一下

我也是解决了温饱问题,生活无忧、工作无忧、家庭无忧,才能有这么多空写写文章,扯扯蛋,真的哪个人也能跟我一样,能静下心来写来写去又赚不到钱啥的,还是需要付出很多精力、代价的,不是吹的一般人写个几百篇原创文章,还是没那么容易的,很多人的知识一方面是没的什么好写,很可能都不知道能写些什么,不管怎么样,在能写,也能得到大家的点击,已经很不错了,很成功了。

很多人,多么想吸引人家的目光,都很难啊,我的点击量、回复量有时候也很让我知足了,大家都懒得看了,那我就离失败越来越近了。

能Google解决的技术,不叫技术。这种技术碰不得。
马伟
只看老赵的吵架文。技术性文章看多了不一定好,限制思路是一方面,另一方面,给你多个选择,意志不坚定的会在各种选择之间摇摆。我经常写东西,经验是:写小说,一定不能多看小说。我培养我lp写小说,结果看了2年,杂七杂八的看了一大堆,没写出两千字出来,为什么呢?没自信。写小说,不要看小说,而是想到一个卖点,就写,然后修改,修改再修改。做技术也是,一个问题或需求,先实现,再修改修改再修改。。。
引用OC Life:
@卡通一下
貌似*日的文章都能看到你在鼓风吹浪,一直强调什么鸡汤,你提出的问题,他给你解答了么?......
如果这就是你所谓的鸡汤,希望你能坚持喝下去。

我能得到您的关注,很是荣幸;同时也为吉日感到荣幸,这说明你也经常光顾吉日的博客,不是吗?

至于你说我是鼓风吹浪,一直强调什么鸡汤,那是因为我在喝汤之前,一定要鼓起腮帮子吹去浮油,否则喝多了对身体不好。如果非要说我,那就当我是个汤勺吧,就是来和弄鸡汤的,呵呵...

对于吉日,你恨也好、骂也好、怒也好,毕竟你自己的内心还是想来看看热闹,否则你怎么知道吉日的那么多事情呢?

我曾与吉日开玩笑,说看他的文章一定要把文章的推荐数和反对数加在一起算,如果平淡无奇,到是索然无味!你看吉日文章有那么高的阅读数,不也能说明问题吗?

说到海洋,我觉得海洋的写作态度要比吉日严肃,也很是可爱,呵呵!

海洋的文章不便在此评论,还是到海洋的博客上再说吧。

{zh1},我要说的是博客园中的一些文章,是属于“心灵鸡汤”类的,是用来滋润人们心灵的,而不是用来学习技术的。如果这类文章能引起您的共鸣,那说明您的心灵确实需要“鸡汤”;如果引起您的反感,那您还是快快地倒掉...

我自己既不需要“鸡汤”,也不反感,因为我就是一个大汤勺!

哈哈...
-----------------
不看行吗?非得每篇文章往首页放,假如你让他放到候选区,或者干脆去新手区(反正你也说了他的文章是给新手看的),阅读数超100都难,再说那个阅读数也没什么意义,又不是不能刷。

海洋是个严肃的人,但是他也乐于分享,至少你对文章提到的技术有啥问题,他看到了也会互相讨论,据理力争都没关系,总比发出来丢在那不管,别人有了技术疑问,就沉默或者指责别人没看懂什么的,你觉得博客弄成这样,又总是发到首页,还装委屈说博客园不容他,csdn抢着邀请,这样有啥意义?

既然你把*日的文章当鸡汤,没当他的文章是技术的,那又何必提什么技术问题了?

后面也不没啥好说的,都扯太远了,您请继续享用,我先找地方吐去。
xiaotie:
@马伟
我经常写东西,经验是:写小说,一定不能多看小说。我培养我lp写小说,结果看了2年,杂七杂八的看了一大堆,没写出两千字出来,为什么呢?没自信。。。

说到自信,我觉得这是最根本的东西,无论做什么事,如果缺乏自信,那什么也做不好。

对于一个自信满满地人来说,看看吉日的文章也没有什么;但对于缺乏自信的人来说,就可能引发焦躁、不安、愤怒,继而引发口水。

其实吉日文章大家看多了,只要一见到标题,就能猜出是吉日文,只是有些人还是忍不住,非要“窥一窥”,然后猛烈地抨击,以彰显自己的正义。更有些人还要到边上吐一吐,不是很好笑吗?
xiaotie:
@卡通一下
海洋的文章没法看啊,南辕北辙。

海洋应当是一个非常有激情的人,他能把自己关在屋内尽情地“造车”。也许他没有多少实战的经验,可他的那份投入,他的那份努力,还是令人感动的。

我们每个人所处的环境不一样,海洋也应当有他自己的一份天地,我还是给予深深地理解。

海洋的文章确实有些东拉西扯的,宽容一些地看,也是挺有意思的。

刚刚看到“世界因你不同”的{zh1}一句,“成功并没有{jd1}的意义,成功,就是做{zh0}的自己,并把{zh0}的你呈现出来”

是啊!我们是否把自己做到{zh0}了呢?
马伟:
引用笨笨的考拉熊:
这点上支持吉日。现在的新人啊,把饭都摆到眼前了,还怪你不拿勺喂他。

引用吉日嘎拉 不仅权限设计:
这很可能表明你还嫩一些,相对有水平的、有点儿基础的人,看个文章的大概就明白是什么意思了,呵呵,看来你还需继续提高了再来读这个文章了,不好意思啊,不是我没写出来知识点,是你没能理解而已,不能怪我了。

引用木鱼:我是来学习的....但是没学到东西...



笨笨的考拉熊兄,你的这个观点我就不太同意.我认为"技术"方面的问题一定要精细化,讲清楚,说明白,而不是点到为止.尤其是这类"优化"话题.
...




呵呵,马兄多虑了,讨论观点而已么,不至于的。

我写文章也是喜欢讲得非常细致的,可以看看我的博客,有的文章我是每一步操作都要截图的。而且一项技术,从操作到原理都会说到,读者照着文章操作,甚至可以一点脑筋不动就做出来。而不是像吉日这样一带而过。

这里我说的不是不要细节,而是说如何写文章是根据每个人的风格不同决定的。一盘文章写的详细,能教会你知识,哪应该心怀感激;如果写的不细,也没啥好说的。因为作者不欠你什么,没必要为你没有学到东西而负责。

不过现在博客园的首页也是够乱的了,真是林子大了啥鸟都有,什么破文章都敢往上放,前几天我都忍不住差点开骂了。我发首页的宗旨只有一条,那就是确保这篇文章肯定对别人的实际工作有帮助才会放,像吉日的这篇文章,以我的标准不但首页,连新手区我都不会放的,只会归档在文章里,为以后做个参考。
SQL Server 2000和SQL Server 2005/2008是不一样的,在2k的时候SQL Server几乎就是个Black box,所以要进行优化的话你可以使用的手段其实是比较有限的,但是还是可以通过Profile来解决大多数问题的。从2005/2008来说,系统体系还是发生了很多的变化,为我们提供了很多手段和方式来进行优化。
不管是Oracle/SQL Server也好,要做好优化,关键是要了解他们的机制,然后采取楼上几位XDJM的优化建议和意见来分析问题,然后制定方案来解决问题,这样的话做到一定的优化还是可以的。当然了,要是系统的架构有问题的话,你可以提升性能的空间的天花板也是很快要被touch的,在那时候得找找别的出路了,一切到{zh1}都是空间和时间的平衡,关键在于自己的取舍。
换个角度来说,单纯讨论Oracle/MS SQL产品其实是无意义的,花钱买了别人的产品,还帮别人吹牛,这样的话难道厂商就会给你打折了吗?No Way!所以没必要进行产品好坏之争,除非Oracle/MS给你们发红包。
郑重声明:资讯 【2000W条数据的Oralce数据库SQL查询优化经验- 机会总会留给有准备的人 ...】由 发布,版权归原作者及其所在单位,其原创性以及文中陈述文字和内容未经(企业库qiyeku.com)证实,请读者仅作参考,并请自行核实相关内容。若本文有侵犯到您的版权, 请你提供相关证明及申请并与我们联系(qiyeku # qq.com)或【在线投诉】,我们审核后将会尽快处理。
—— 相关资讯 ——