收获，不止Oracle

书籍目录

上篇开启惊喜之门——带意识地学Oracle 第1章意识，少做事从学习开始2 1.1选择先学什么颇有学问2 1.1.1梁老师课堂爆笑开场2 1.1.2看似跑题的手机分类4 1.1.3学什么先了解做什么5 1.2善于规划分类才有效果7 1.2.1分类与角色密切相关7 1.2.2角色自我认识有讲究9 1.3明白学以致用方有意义11 第2章震惊，体验物理体系之旅13 2.1必须提及的系列知识13 2.2物理体系从老余开店慢慢铺开16 2.2.1老余的三个小故事16 2.2.1.1顾客的尺寸16 2.2.1.2有效的调整17 2.2.1.3记录的习惯18 2.2.2体系结构原理初探20 2.2.2.1从一普通查询SQL说起20 2.2.2.2老余故事终现用心良苦23 2.2.2.3一起体会Oracle代价27 2.2.3体系结构原理再探30 2.2.3.1从一普通更新语句说起30 2.2.3.2体系结构中提交的探讨34 2.2.3.3劳模的评选38 2.2.3.4回滚的研究40 2.2.3.5一致的查询43 2.2.3.6一致读的原理46 2.2.3.7实践的体会49 2.3体系学习让SQL性能提升千倍65 2.3.1一起探索体系学习的意义65 2.3.1.1同学们不知所学何用66 2.3.1.2实际上大有用武之地67 2.3.2单车到飞船的经典之旅70 2.3.2.1未优化前，单车速度70 2.3.2.2绑定变量，摩托速度72 2.3.2.3静态改写，汽车速度74 2.3.2.4批量提交，动车速度75 2.3.2.5集合写法，飞机速度77 2.3.2.6直接路径，火箭速度78 2.3.2.7并行设置，飞船速度79 2.3.3精彩的总结与课程展望80 2.3.3.1最大的收获应该是思想80 2.3.3.2老师的课程展望与规划81 第3章神奇，走进逻辑体系世界84 3.1长幼有序的逻辑体系84 3.2逻辑体系从老余养殖细细说起85 3.2.1农场之体系逻辑结构85 3.2.2农场之BLOCK漫谈89 3.2.3农场之区与段91 3.2.4农场之表空间的分类93 3.2.4.1表空间与系统农场93 3.2.4.2表空间与临时农场93 3.2.4.3表空间与回滚农场94 3.2.5逻辑结构之初次体会94 3.2.5.1逻辑结构之BLOCK94 3.2.5.2逻辑结构之TABLESPACE95 3.2.5.3逻辑结构之USER97 3.2.5.4逻辑结构之EXTENT97 3.2.5.5逻辑结构之SEGMENT98 3.2.6逻辑结构之二次体会100 3.2.6.1BLOCK的大小与调整100 3.2.6.2PCTFREE参数与调整101 3.2.6.3PCTFREE与生效范围102 3.2.6.4EXTENT尺寸与调整103 3.2.7逻辑结构之三次体会104 3.2.7.1已用与未用表空间情况104 3.2.7.2表空间大小与自动扩展105 3.2.7.3回滚表空间新建与切换109 3.2.7.4临时表空间新建与切换111 3.2.7.5临时表空间组及其妙用114 3.3课程结束你给程序安上了翅膀117 3.3.1过度扩展与性能117 3.3.2PCTFREE与性能120 3.3.3行迁移与优化123 3.3.4块的大小与应用124 第4章祝贺，表的设计成就英雄131 4.1表的设计之五朵金花131 4.2表的特性从老余一家展开描述132 4.2.1老余一家各施所长132 4.2.2普通堆表不足之处132 4.2.2.1表更新日志开销较大133 4.2.2.2delete无法释放空间136 4.2.2.3表记录太大检索较慢139 4.2.2.4索引回表读开销很大140 4.2.2.5有序插入却难有序读出143 4.2.3奇特的全局临时表146 4.2.3.1分析全局临时表的类型146 4.2.3.2观察各类DML的REDO量147 4.2.3.3全局临时表两大重要特性149 4.2.4神通广大的分区表153 4.2.4.1分区表类型及原理155 4.2.4.2分区表最实用的特性165 4.2.4.3分区索引类型简述176 4.2.4.4分区表之相关陷阱177 4.2.5有趣的索引组织表184 4.2.6簇表的介绍及应用187 4.3理解表设计的你成为项目组英雄189 第5章惊叹，索引天地妙不可言191 5.1看似简单无趣的索引知识191 5.2索引探秘从小余缉凶拉开帷幕192 5.2.1BTREE索引的精彩世界192 5.2.1.1BTREE索引结构图展现192 5.2.1.2到底是物理还是逻辑结构194 5.2.1.3索引结构三大重要特点198 5.2.1.4插播小余缉凶精彩故事201 5.2.1.5妙用三特征之高度较低203 5.2.1.6巧用三特征之存储列值219 5.2.1.7活用三特征之索引有序248 5.2.1.8不可不说的主外键设计265 5.2.1.9组合索引高效设计要领272 5.2.1.10变换角度看索引的危害289 5.2.1.11如何合理控制索引数量295 5.2.2位图索引的玫瑰花之刺297 5.2.2.1统计条数奋勇夺冠297 5.2.2.2即席查询一骑绝尘302 5.2.2.3遭遇更新苦不堪言306 5.2.2.4重复度低一败涂地309 5.2.2.5了解结构真相大白311 5.2.3小心函数索引步步陷阱315 5.2.3.1列运算让索引失去作用315 5.2.3.2函数索引是这样应用的317 5.2.3.3避免列运算的经典案例319 5.3索引让一系列最熟悉的SQL飞起来了325 第6章经典，表的连接学以致用327 6.1表的连接之江南三剑客327 6.2三大类型从小余跳舞一一道来328 6.2.1跳舞也能跳出连接类型328 6.2.1.1感觉怪异的嵌套循环328 6.2.1.2排序合并及哈希连接329 6.2.2各类连接访问次数差异330 6.2.2.1嵌套循环的表访问次数330 6.2.2.2哈希连接的表访问次数337 6.2.2.3排序合并的表访问次数340 6.2.3各类连接驱动顺序区别341 6.2.3.1嵌套循环的表驱动顺序341 6.2.3.2哈希连接的表驱动顺序343 6.2.3.3排序合并的表驱动顺序345 6.2.4各类连接排序情况分析347 6.2.4.1除嵌套循环都需排序347 6.2.4.2排序只需取部分字段347 6.2.4.3关于排序的经典案例349 6.2.5各类连接限制场景对比350 6.2.5.1哈希连接的限制350 6.2.5.2排序合并的限制353 6.2.5.3嵌套循环无限制355 6.3你动手装备的表连接威震三军355 6.3.1嵌套循环与索引356 6.3.2哈希连接与索引362 6.3.3排序合并与索引363 下篇飞翔意识天空——思想与案例的分享 第7章搞定！不靠技术靠菜刀368 7.1SQL被一刀剁了369 7.2整个模块丢弃了370 7.3调用次数减少了371 7.4排序不再需要了372 7.5大表砍成小表了373 7.6排重操作消失了373 7.7插入阻碍小多了374 7.8迁移事情不做了375 第8章升级！靠技术改隐形刀377 8.1大表等同小表了378 8.2大表切成小表了379 8.3索引变身小表了380 8.4删除动作不做了380 8.5清表角度变换了381 8.6提交次数缩减了382 8.7迁移越来越快了384 8.8SQL语句精简了385 第9章提问，也是智慧的体现391 9.1描述要考虑周全392 9.2用词要尽量准确393 9.3说明要力求简洁394 9.4问过的避免再问396 9.5能搜能试不急问396 第10章买鱼，居然买出方法论398 10.1小余买鱼系列故事398 10.1.1诊断与改进398 10.1.2需求与设计401 10.1.3资源的利用403 10.1.4真正的需求404 10.2买鱼买出了方法论405 10.2.1一套流程405 10.2.2两大法宝407 10.3方法论的应用案例408 10.3.1从我们的这一套流程说起408 10.3.1.1诊断408 10.3.1.2改进优化（首次优化）409 10.3.1.3需求与设计（再次优化）410 10.3.1.4资源利用（花絮）412 10.3.2案例映衬了经典两大法宝412 第11章宝典，规范让你少做事414 11.1抓狂，为何事总忙不完415 11.1.1技术能力不足的新人们415 11.1.2不懂提问智慧的求助者415 11.1.3产生各种失误的粗心者416 11.1.3.1啊，小黄的DDL惹祸416 11.1.3.2惨，老师登错环境了417 11.1.3.3糟，小罗忘操作 11.1.4解决问题缓慢的技术员419 11.1.4.1优化效率低下的小高419 11.1.4.2为何老师能快速解决420 11.1.5陷入种种困境的开发者422 11.1.5.1超长SQL使小郑烦恼422 11.1.5.2缺少注释让小叶沮丧422 11.1.6总是考虑不全的设计者423 11.1.6.1未提前规划的王工423 11.1.6.2不了解特性的刘工424 11.2淡定，规范少做无谓事425 11.2.1学习规范——促成新人快速成长426 11.2.2求助规范——引导求助不再迷糊427 11.2.3操作规范——协助粗心者不犯错428 11.2.4流程规范——保障问题快速解决429 11.2.4.1动态整体429 11.2.4.2动态局部432 11.2.4.3静态整体439 11.2.4.4静态局部448 11.2.5开发规范——让开发者驾轻就熟451 11.2.5.1SQL编写规范452 11.2.5.2PL/SQL编写规范455 11.2.6设计规范——助设计者运筹帷幄457 11.2.6.1表规范458 11.2.6.2索引规范461 11.2.6.3环境参数规范467 11.2.6.4命名规范469

编辑推荐

《收获,不止Oracle》颠覆IT技术图书的传统写作方式，在妙趣横生的故事中学到Oracle核心知识与优化方法论，让你摆脱技术束缚，超越技术。

前言

别出心裁 另出蹊径——与梁敬彬先生序敬彬的新书就要出版，邀我写一点感受，于是就有了这一段文字。我和敬彬相识是在2010年，那时我正在编辑《Oracle DBA手记》一书，偶然被他发表在ITPUB论坛上的一篇文章所吸引，那篇文章的题目是《DBA 小故事之SQL诊断》，其内容清晰、行文引人，于是就和他约了那篇稿子加入到书中，期间邮件往来再到北京会面，就此熟识。从当时的一篇文章到今天的一本书，我能够清晰地看到作者一以贯之的思考和叙述方式，这种积累与坚持也正是作者成长和成功的要素之一。当时那篇文章的感受和今天这本书是类似的，作者能够用曲折的笔触将自己的经历真实生动地再现出来，并且带领读者一起经历一次思维的探索，这是属于他的独特风格。作者在书中反复传达的核心观点是：Oracle数据库看似艰深的原理实际上和生活中的基本常识并无二致。理解了这一层意思，就能够克服对于这门技艺的畏惧之心，此后的学习自然就能够顺风顺水。诚然如此，我也经常和朋友们说，对于Oracle的很多艰深算法，如果由我们去深思熟虑，其结果都必然大致相同。类似HASH原理，布隆过滤等算法，理解了你就只觉得巧妙而不觉艰深。现在梁老师就为我们寻找了一系列源于生活、循序渐进的学习路线，如果你能够细心领会，就会觉得这一门技艺实在是趣味横生。盖国强（eygle）Oracle ACE总监云和恩墨创始人ACOUG创始人

内容概要

梁敬彬，网名wabjtam123，任ITPUB版主、ITPUB社区专家、福建富士通公司数据库专家。参与编写过《剑破冰山——Oracle开发艺术》、《DBA手记2》等技术书籍，多年从事电信相关行业工作，负责系统架构设计、优化、培训等工作，有着丰富的数据库管理、设计、开发、培训经验和电信行业经验。梁敬弘，清华大学计算机系博士毕业，在计算机领域和金融领域皆有建树，拥有多项计算机相关核心专利技术的同时还拥有金融行业的CFP等高级认证。现就职于华夏银行总行。

名人推荐

岂曰无衣，与子同袍。此书必为IT行业带来一股清新之风，打造出IT书籍的一段传奇佳话，成就一部永不过时的经典力作！我相信，此书将为广大读者开启惊喜之心扉，让读者飞翔在思想的天空、遨游在方法论的海洋、采摘到技术的累累硕果，相信收获远不止Oracle！——福富软件公司副董事长、总经理：杨林作者在书中反复传达的核心观点是：Oracle数据库看似艰深的原理实际上和生活中的基本常识并无二致。理解了这一层意思，就能够克服对于这门技艺的畏惧之心，此后的学习自然就能够顺风顺水。诚然如此，我也经常和朋友们说，对于Oracle的很多艰深算法，如果由我们去深思熟虑，其结果都必然大致相同。类似HASH原理，布隆过滤等算法，理解了你就只觉得巧妙而不觉艰深。现在梁老师就为我们寻找了一系列源于生活、循序渐进的学习路线，如果你能够细心领会，就会觉得这一门技艺实在是趣味横生。——盖国强（eygle）Oracle ACE总监、云和恩墨创始人、ACOUG创始人我在ITPUB认识梁敬彬先生始，就拜读他当时参与的大作《剑破冰山——Oracle开发艺术》，直至今天，这本书里的部分内容在行业里还发挥着重要影响力。从事数据库事业多年，读过无数的技术书，有洋洋万言的，有短小精悍的，但大多写得正儿八经，有距离感，还有点冷。梁敬彬先生的新书，用生动的故事形式叙述复杂技术，开创数据库技术书籍故事化的写作先河。梁先生技术功底和文字功底同样深厚，更重要的是具有作为讲师那种缜密、体系化的思维方式，以及对读者心思的透视力，因此成书脉络清晰，里面还不断穿插许多人生哲理，技术前瞻，让人获益良多。这本书非常适合入行者和在行业里谋求上升的同仁阅读，动人的文笔可以让你一口气读完这本书，而且完全没有读其它技术书籍时那种头晕脑胀，昏昏入睡的感觉。这是一本值得向行业推介的优秀技术书籍。——黄志洪(tigerfish) 中国数据库社区ITPUB创始人多年前作为DBA时我曾经总结过，到底是什么后天原因能导致人和人之间的学习结果发生重大差异，其中有一点就是思维方式。于是我尝试在思维方式方面去影响身边的一些人，最后这些人在各自的领域也都获得了成功，而在此之前他们却是默默无闻。思维方式可以由长期的训练而固化下来，但若是无人在身边影响你，那么最好就是你自己有意识的发生改变。敬彬此书就是用诙谐幽默的语言生动地引导大家在意识层面发生改变，然后逐步转化为行动上的改变，按此坚持几年下来，相信每个人都能迈上自己新的台阶，这的确早已超越oracle的范畴，对我们诸多方面都有益处。——冯春培 (biti_rainy)支付宝平台数据部资深总监敬彬兄这本书有着与市场上其他Oracle书籍与众不同的特点，他通过一个个精彩的小故事，串起Oracle的核心知识和优化方法论，并时刻强调学习和工作的意识，如何不被技术束缚，如何跳出技术，意识和方法真的很重要。相信读完本书，你的收获，绝对不止Oracle！——丁俊（dingjun123）ITPUB Oracle开发版资深版主，《剑破冰山——Oracle开发艺术》副主编通读本书，如醍醐灌顶，豁然开朗，本书从实战出发，出发于技术，而超脱于意识，回味无穷，作者拥有多年的Oracle应用和体系架构设计的经验，付出了不亚于任何人的努力，总结出众多独到的经验，不失为一本好书，为学习和使用Oracle的技术人员带来诸多益处。——傅祥文，福富软件公司运营总监由梁敬彬、梁敬弘兄弟合作的《收获，不止Oracle》一书问世了。这对学习和从事数据库相关事务的业内人员来说，是一件幸事。读一本技术方面的书，或修一门课程、听一个讲座，大凡可能有三方面的收获：掌握相关的知识，提高解决问题的能力，激发学习、探讨有关问题的兴趣和热情。这些可能的收获不在一个层面上，后两者更为可贵。梁敬彬梁敬弘兄弟的这本书恰恰给读者提供了这样的机会。当然，要有真收获，还要有真努力。 梁敬弘曾是我的学生，不仅学业专精，围棋也下得很不错，是一个真诚而聪明的小伙子，跟他的哥哥相比，内向一些。梁敬彬与弟弟相比更善于沟通和表达，是一个数据库方面的专家，也是一个很好的教师。在此，预祝本书的出版获得成功，同时也祝兄弟二人在事业上不断取得新的成就。——黄连生，清华大学计算机系教授曾经有Oracle的初学者问我，怎么开始学习Oracle？那时候我的答案很简单：“去下载Oracle的在线文档，包括Database Concept、Administrator’s Guide，然后开始学着做实验。”诚然，对学习技术而言，在线文档是一个不可多得的利器，但是，对于一个刚刚开始接触Oracle的人来说，要从枯燥的英文文档中去学习和理解Oracle的技术体系，也许有点勉为其难。 就算是市面上众多的Oracle技术书籍，多数也是堆砌满了技术细节，随时可能吓跑初学者。好在，现在梁敬彬先生通过自己在日常工作和培训中的磨练，把自己对Oracle技术的感悟，通过一个一个的小故事，浅显而又形象地展现了出来。对于初学者来说，可以慢慢地在一个个小故事中去了解Oracle数据库。读完这本书，你也许会恍然大悟：“哦，原来Oracle是这样子的。”——罗海雄（rollingpig）ITPUB Oracle管理版资深版主大师这本书，初学者乍一看，挺深入，老手乍一看，挺简单。但真正看完，才知道什么是不简单下的简单，简单中的不简单！——新浪微博网友

章节摘录

版权页：   插图：   “小莲同学一针见血地指出了梁老师的错误或者说是描述不完整的部分，非常好！”梁老师笑着说，“我每次给别人培训时都故意说到前面就结束了，然后等同学来发现这个漏洞，但是很少有人质疑，小莲同学非常认真，值得表扬。 这里的语句是select*from t where id=12，这个*表示要展现t表的所有字段，显然只访问索引是不可能包含表的所有字段的，因为该索引只是对id列建索引，也就存储了id列的信息而已。因此上述查询访问完索引块后，必然要再访问数据块，比较快捷的方法是用索引块存储的rowid来快速检索数据块（具体在后续章节会描述），由此证明我之前假想的3次IO是错误的，理应增加一次从索引块到数据块获取各个列信息的检索动作，至少是4次10才对。 现在大家都没疑问了吧?” 小莲和同学们都纷纷点头，大家都觉得没疑问了。 “既然大家都没疑问了，梁老师想问大家一个问题，什么情况下查询可以只访问索引而不访问表呢？” “梁老师，我知道了，如果查询只检索索引列信息，就可以不访问表了，比如查询改成select id from t where id=12时就是这种情况。”晶晶起身回答。 “非常正确，虽然select id from t where id=12的写法会让人觉得有些奇怪，但是从回答这个问题的角度来看，却是百分之百正确的回答！没理解的同学请仔细回味我说过的这句话： 其中Leaf（叶子块）主要存储了key column value（索引列具体值）以及能具体定位到数据块所在位置的rowid（注意区分索引块和数据块）。 这句话很经典哦，大家要牢记在心，我相信小莲和晶晶已经完全明白这句话的意思了，对不对啊两位同学？” 两位同学都不好意思地笑了。 5.2.1.2到底是物理还是逻辑结构 “同学们，select*from t where id=12这个语句在索引中检索时的3次IO描述大家还记忆犹新吧，大家说说看这个索引查询示例图描述的是一种逻辑结构还是物理结构呢? 我再解释一下，物理结构可以理解为真正存在根、茎、叶的BLOCK。而逻辑结构可以理解为并没有存在根、茎的BLOCK，只是一种指针或者说一种内部算法。 有奖竞猜，大家踊跃发言。” “逻辑结构！”台下几乎没有听到有人说是物理结构的。 “换句话说就是大家都认为不存在真正的根、茎、叶的块组成了这些对象，是这样吗？” “是！”虽然大家都回答是，但是可以看出来不少同学们还是有些不敢确定。 “那答案到底是什么呢？老师不着急公布答案，大家跟我一起做一个试验吧，不过这次试验与之前的风格不同，老师并不执行任何脚本，而是通过一系列有趣的看图说话让大家跟梁老师一起想象，大家要打起精神认真听。

---

 收获，不止Oracle下载 精选章节试读 更多精彩书评

---