《Origin 9.0科技绘图与数据分析超级学习手册》一1.4　本章小结

第一部分 内 政 篇 万物之始,大道至简,衍化至繁. --老子,<道德经> 第1章 大 道 至 简 万物之始,大道至简,衍化至繁.世间一切事物在刚刚开始的时候,都是非常简单的,是为大道,随着事物不断地发展,其衍变出来各种复杂的局面.然而,追本溯源,仍然会发现复杂局面下真正在左右事物的还是那些最基本的东西--大道.如果能牢牢把握住这些被认作是"大道"的东西,再复杂的局面也自然会变得简单. 近些年来,在数据库领域里,可谓群雄逐鹿,志在中原.他们各自有各自的特色,相互间也甚是喜欢

第2章 高效B树索引 本章要点: 索引扫描识别,介绍索引的基本概念及展开讨论各种索引的扫描方式. 索引与排序,介绍索引在排序过程中的作用和意义. 索引设计优化,深入解析索引设计的方法技巧,以及设计索引的影响因素. 索引分裂,深入剖析索引树分裂生长原理及因此带来的问题和解决方法. 索引维护,围绕索引重建探讨索引后期维护的方法. 众所周知,索引不论在数据库设计过程中,还是在应用程序开发过程中都是一个至关重要的方面.索引的使用正确与否直接影响到应用程序的性能,并且它是贯穿于设计.开发.运维的各个阶段的

1.4 本章小结 纵观本章,主要介绍了一下高并发Oracle数据库系统的特点.难点以及架构和设计的基本思路,并闲话了一些时下流行的话题.下一章我们将进入本书的正题,给读者们介绍如何在Oracle数据库里进行高效索引的设计.

1.3 在Oracle的世界里 如果你是一位Oracle数据库的使用者,那么我们说你将是立足在Oracle的世界里的.本书的主旨也是以此为出发点,立足Oracle的世界,以海纳百川的胸怀选择性吸收各种数据库的使用.立足点的不同,同样会影响到我们视角不同,那么在Oracle的世界里的高并发数据库系统架构设计将会是怎么样的呢?这也将是本书需要给读者们介绍的.相信在每一个Oracle数据库用户的眼中都有其独特的风景,对Oracle的理解可以是技术的,更可以是艺术的.在讨论中,我经常提及的一个观点:"将

前 言 为什么要写这本书 写一本Oracle数据库方面的技术书籍,是我一个持续了四五年的想法.本着自我总结和快乐分享的初衷,不只一次地咨询过eygle大师关于写书的细节,eygle大师也热情地予以指导.遗憾的是,总是因为这样那样的原因,这个想法迟迟不能落地. 2013年的夏天,我有幸作为微博特使参与了甲骨文全球大会(Oracle Open World)上海站的活动,跟一位甲骨文的朋友闲谈中,不经意聊到了与Oracle数据库"共事"已经快十年了.朋友说我应该有不少心得了,鼓励我花一年的时

2.3 索引设计优化 现在,我们知道了B树索引的结构特点,也了解到其对查询和排序优化的意义,但是这并不代表我们就能建好用好索引了.在实际工作中,是不是还是会遇到走了索引反而查询变慢的情况呢?虽然说不是所有的情况下索引扫描都是优于全表扫描的,但是对于一套设计成熟的系统来说,索引扫描往往是值得坚持的,应该定期进行全库SQL语句执行计划的审查,抓出全表扫描的SQL进行优化. 说一千道一万,我们创建索引就是为了使用索引,尽可能地使查询操作能够走索引.但是,很遗憾,不是我们说走索引就能走索引,还是需要取决

1.1 初见高并发 高并发这个概念并不新鲜,可以说有数据库的地方都有可能面临高并发的问题.在数据库里,高并发问题主要集中在两个方面:读的高并发.写的高并发,两者看起来都不是很复杂,然而实际情况往往是读和写会交织在一起,并同时呈现出高并发的问题.这个时候,相信很多读者都会提出一个观点:做读写分离嘛.是的,这是一个不错的主意,但只是一个治标不治本的主意.业务系统的耦合度很高,是不可能实现业务层级的读写分离的.在架构设计的过程中,不能驻足于技术层面,还是需要渗透到业务层面去的.不论是业务驱动技术,还是

1.2 说句时髦话 活在当下,对于IT人来说,是再合适不过的说法了.IT行业的发展速度堪比高铁.火箭,每一个IT人都在担心自己的知识领域明天就要过时,不得不每天学习新的知识,无奈的是跑得再快也没有办法追得上火箭.在数据库的领域里,也是时刻都在出现新概念和新产品.创新,成了每个人.每个企业都在不断追逐的东西.现有的东西,做好了是应该的,做不好要接受惩罚:创新的东西,做不好是应该的,做好就是绩效.当创新和KPI绩效直接联系到一起的时候,大家都不再是为了创新而去创新,而是为了KPI而去创新,甚至出现了

2.5 索引维护 索引对于性能保障的重要性是不言而喻的,一个优质的索引是性能的润滑剂,相反,劣质的索引将是性能的"绞肉机".通过2.4节的介绍,我们了解到一个设计优良的索引,在经过日常业务应用,特别是OLTP的高并发"摧残"之后,将变得满目疮痍,原本优质的索引也可能转变为劣质的. 这就需要DBA的介入,找到劣质的索引,并恢复其优质的本相.索引的后期维护可能是DBA们日常维护工作中非常重要的一部分,同时也可能是最费时费力的一部分.有人可能会简单地概括一下:"

2.4 索引分裂 通过前面三节的介绍,相信各位读者已经能对索引的设计及其影响因素有了一定的把握,接下来两节我们将进行到索引新建后的维护阶段.先想一想,索引为什么需要维护?因为它不能保证高效的查询和DML操作,甚至成了一种拖累,或者大家都很"喜欢"它,它有些不堪重负了.这些问题对我们来说都是不能置之不理的,否则宁可不建索引.知其然必知其所以然,要想解决索引的问题,需要先知道这些问题是怎么产生的.我们知道B树索引的结构就像一棵树一样,这棵树随着业务数据的增加,也是会慢慢生长起来的,自然也有