收获，不止Oracle（顶级专家盖国强冯春培黄志洪等联袂力荐）

最新推荐文章于 2023-01-29 14:35:24 发布

又是一个装逼的

最新推荐文章于 2023-01-29 14:35:24 发布

阅读量393

点赞数

本文链接：https://blog.csdn.net/akdjhf/article/details/87888970

版权

分享一下我老师大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow

收获，不止Oracle（顶级专家盖国强、冯春培、黄志洪等联袂力荐）

梁敬彬梁敬弘著

ISBN 978-7-121-20070-0

2013年4月出版

定价：59.00元

480页

16开

编辑推荐

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

内容提要

在这本书里读者将会跟随作者一同对Oracle数据库的相关知识进行梳理，最终共同提炼出必须最先掌握的那部分知识，无论你是数据库开发、管理、优化、设计人员，还是从事Java、C的开发人员。接下来作者再将这部分知识中最实用的内容进一步提炼，浓缩出最精华的部分，分享给大家。这是二八现象的一次经典应用。

这部分知识就是Oracle的物理体系结构、逻辑体系结构、表、索引以及表连接五大部分。通过阅读这些章节，读者将会在最短时间内以一种有史以来最轻松的方式，完成对Oracle数据库的整体认识，不仅能在工作中解决常规问题，还能具备一定的设计和调优能力。相信通过这些章节的学习，会给读者的Oracle学习带来极大的收获。

然而，作者最希望看到的是：让读者的收获，不止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 逻辑结构之 BLOCK 94

3.2.5.2 逻辑结构之 TABLESPACE 95

3.2.5.3 逻辑结构之 USER 97

3.2.5.4 逻辑结构之 EXTENT 97

3.2.5.5 逻辑结构之 SEGMENT 98

3.2.6 逻辑结构之二次体会 100

3.2.6.1 BLOCK的大小与调整 100

3.2.6.2 PCTFREE参数与调整 101

3.2.6.3 PCTFREE与生效范围 102

3.2.6.4 EXTENT 尺寸与调整 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.2 PCTFREE与性能 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.2 delete无法释放空间 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.1 BTREE索引的精彩世界 192

5.2.1.1 BTREE索引结构图展现 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.1 SQL被一刀剁了 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.8 SQL语句精简了 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 糟，小罗忘操作…… 417

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.1 SQL编写规范 452

11.2.5.2 PL/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

精彩节摘

2.3.2 单车到飞船的经典之旅

“刚才老师回答了不少同学的疑问，说明了学习体系结构还是有意义的。看来只要善于思考，善于联系，我们就能很容易地应用所学的知识解决遇到的问题。

现在我给大家讲一个具体的案例，通过执行系列等价SQL语句的性能差异，来分析其中的原因所在。

2.3.2.1 未优化前，单车速度

首先构造环境，保证下列语句执行过了，t表已经存在：

sqlplus ljb/ljb

drop table t purge;

create table t ( x int );

--将共享池清空

alter system flush shared_pool;

脚本2-29 单车到飞船试验前的准备工作

有一个开发人员写了类似如下的一个简单存储过程，实现了将1到10万的值插入t表的需求，具体如下：

create or replace procedure proc1

begin

for i in 1 .. 100000

loop

execute immediate

'insert into t values ( '||i||')';

commit;

end loop;

end;

----这里要记得先预先执行一遍，将过程创建起来！

脚本2-30 单车到飞船试验前构造proc1

该语句从需求实现上没有任何问题，我们执行如下：

SQL> connect ljb/ljb

已连接。

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

SQL> exec proc1 ;

PL/SQL 过程已成功完成。

已用时间: 00: 00: 42.87

SQL> select count(*) from t;

COUNT(*)

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

100000

脚本2-31 首次试验42秒完成，仅是单车速度

该语句用42秒时间完成10万条记录的插入，大家觉得速度快吗？”

“1秒钟插入2千多条记录，速度好快啊！”小莲在数学上的反应还是很敏捷。

“哦，你希望还能更快一点吗？”梁老师问。

“哦，当然希望了，肯定是越快越好了。”小莲回答得不假思索。

“其实这个简单的过程如果想更快，靠的就是对体系结构的理解，下面大家跟我查询一下该过程执行中，数据库共享池中的相关情况。

共享池中缓存下来的SQL语句以及HASH出来的唯一值，都可以在v$sql中对应的SQL_TEXT 和SQL_ID字段中查询到，而解析的次数和执行的次数分别可以从PARSE_CALL和EXECUTIONS字段中获取。

由于这个过程PROC1执行的是insert into t 的系列插入，于是我们执行如下语句来查询PROC1在数据库共享池中执行的情况，具体如下：

select t.sql_text, t.sql_id,t.PARSE_CALLS, t.EXECUTIONS

from v$sql t

where sql_text like '%insert into t values%';

脚本2-32 原来是因为未用绑定变量

为了让SQL语句及展现结果看起来更美观，我将上述SQL在PL/SQL DEVELOPER工具中查询（这个工具有着很友好的界面，尤其适合数据库开发人员使用，因此除了介绍先前的sqlplus 工具外，这里也顺道提一下这个PL/SQL DEVELOPER工具），发现共享池中有大量的类似SQL语句，而SQL_ID各自不同，每个语句都只是解析1次，执行1次，解析了10万次了，怪不得速度如此之慢，如图2-26所示。

图2-26 绑定变量

2.3.2.2 绑定变量，摩托速度

此时我们这么想，要是insert into t values (99898)、insert into t values (99762) 等这10万条语句如果都能合并成一种写法，比如用变量代替具体值，成为insert into t values (:X) ，那岂不是这10万条语句可以被HASH成一个SQL_ID值，不就可以做到解析1次，执行10万次了？这就大大减少了解析时间。

这就是数据库的一个典型优化，绑定变量优化！

接下来我们将proc1改进为proc2，具体写法如下：

create or replace procedure proc2

begin

for i in 1 .. 100000

loop

execute immediate

'insert into t values ( :x )' using i;

commit;

end loop;

end;

----这里要记得先预先执行一遍，将过程创建起来！

脚本2-33 第2次改进，将proc1改造成有绑定变量的proc2

接下来我们继续执行测试proc2过程（注意表重建的目的是为了公平，测试都在无记录的空表上进行，并且共享池都清空）：

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

已用时间: 00: 00: 00.00

SQL> exec proc2;

PL/SQL 过程已成功完成。

已用时间: 00: 00: 08.41

SQL> select count(*) from t;

COUNT(*)

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

100000

脚本2-34 第2次改进后8秒完成，单车变摩托

这次我们惊奇地发现，速度从原来的42.87秒缩减为8.41秒，大幅度提升了，每秒插入记录数达到1万多条，大大超过之前的每秒插入2千多条的速度，为什么会这么神奇呢？”梁老师停下来问大家。

“因为语句被绑定变量了，解析次数变少了！”梁老师的话同学们记得很牢。

“很好，那我们一起看看吧，看看有啥变化（如图2-27所示）：

图2-27 解析与执行次数

虽然插入的语句值各不相同，但是都被绑定为:x，所以被HASH成唯一一个HASH值，名称为dxz576128adaw，很明显可以看出解析1次，执行10万次，这就是速度大幅度提升的原因了。

这下大家对这个速度满意了吧。”

小莲这下才发现，原来简单的体系结构后面还真有不少玄机啊，也不只是上堂课梁老师说的加大减少共享池这么简单，小莲觉得今天的课太值了。

2.3.2.3 静态改写，汽车速度

“大家还想不想再快一点？”梁老师这次开口吓了大家一跳。

“梁老师您太贪心了吧！”晶晶打趣地说道，看来课堂上同学们还真是被梁老师带动得无拘无束了，什么话都敢说啊。

“其实真的是还能再快的，你们看看这两个过程，是否觉得哪里写得有点别扭？”梁老师提醒大家认真看proc1和proc2。

“梁老师，这个execute immediate和双引号是啥意思啊，为什么不直接写成insert into t values (i)啊？”刚才开玩笑的曾祥也提问了。

“不错！终于看出来了，execute immediate是一种动态SQL的写法，常用于表名字段名是变量、入参的情况，由于表名都不知道，所以当然不能直接写SQL语句了，所以要靠动态SQL语句根据传入的表名参数，来拼成一条SQL语句，由execute immediate调用执行。但是这里显然不需要多此一举，因为insert into t values (i)完全可以满足需求，表名就是t啊。

我们来改写成proc3，如下：

create or replace procedure proc3

begin

for i in 1 .. 100000

loop

insert into t values (i);

commit;

end loop;

end;

----这里要记得先预先执行一遍，将过程创建起来！

脚本2-35 第3次改进，将proc2改造成静态SQL的proc3

接下来我们继续测试proc3的性能，也是在公平的环境下操作的，如下：

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

SQL> exec proc3;

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.25

SQL> select count(*) from t;

COUNT(*)

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

100000

脚本2-36 第3次改进后6秒完成，摩托变汽车

大家看看，现在是什么情况？” 梁老师笑着说。

“哇，又快了！”晶晶惊叫起来，引来了一片笑声。

“为什么会快了，我们分析分析，这个语句肯定有用到绑定变量，一般来说，静态SQL会自动使用绑定变量，我们来查看查看（如图2-28所示）。

图2-28 静态SQL解析与执行次数

果然如此，proc3也实现了绑定变量，而且动态SQL的特点是执行过程中再解析，而静态SQL的特点是编译的过程就解析好了。这点差别就是速度再度提升的原因。现在大家对这个速度满意了吧。”

台下纷纷点头。

2.3.2.4 批量提交，动车速度

“还能再快一点吗？”梁老师再次发问引发台下一片大笑，因为大家这时都认为老师是在开玩笑。

“别笑，我可不是开玩笑哦，同学们再执行这个proc3，看看有啥新发现。”

“梁老师，我看到commit了，我觉得应该放在循环的外面而不是里面。放在里面意味着每插入1条，就要提交1次，那放在循环里就要提交10万次，而放在循环外就是全部插入完后提交1次，我觉得少提交更好。”细心的小莲发现了commit 位置的不同。

“说得非常好，commit触发LGWR将REDO BUFFER写出到REDO BUFFER中，并且将回滚段的活动事务标记为不活动，同时让回滚段中记录对应前镜像记录的所在位置标记为可以重写，切记commit可不是写数据的动作哦，写数据将数据从DATA BUFFER刷出磁盘是由CKPT决定的，前面大家应该有印象。

所以commit做的事情开销并不大，单次提交可能需要0.001秒即可完成。另外不管多大批量操作后的提交，仅针对commit而言，也是做这三件事，所花费的总时间不可能超过1秒。打个比方，批量100万条更新执行后完成commit的提交可能也就需要0.8秒，但是100万×0.001的时间可是远大于1×0.8的时间了。

下面我们来做做试验，将proc3改写为proc4，具体如下：

create or replace procedure proc4

begin

for i in 1 .. 100000

loop

insert into t values (i);

end loop;

commit;

end;

----这里要记得先预先执行一遍，将过程创建起来！

脚本2-37 第4次改进，将proc3改造成提交在循环外的proc4

接下来我们继续测试proc4的性能，也是在公平的环境下操作的，如下：

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

SQL> exec proc4;

PL/SQL 过程已成功完成。

已用时间: 00: 00: 02.18

SQL> select count(*) from t;

COUNT(*)

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

100000

脚本2-38 第4次改进后2秒完成，汽车变动车

速度是多少？”梁老师回头看着大家。

“哇，2秒就完成了！”还是晶晶的惊叫声。

“等同于每秒5万条记录，原先可是每秒2千多条啊，不可思议！”小莲数学换算总是最快。

2.3.2.5 集合写法，飞机速度

“还能更快吗？”梁老师没完没了啊。

“不可能！”这下同学肆无忌惮地大笑了，他们知道梁老师这回肯定是故意的了。

“不可能？看来你们又认为老师在开玩笑了，如果老师能让插入该表的动作更快，你们请老师吃饭，否则老师请你们吃饭？”

“没问题！”同学们应答得好干脆啊，他们其实心里也知道，这请客的说法一定是开玩笑，课堂的气氛被调到了最高潮了。

“好吧，同学们，大家看这条SQL语句的写法，如下：

insert into t select rownum from dual connect by level<=100000;

表示我从1到10万依次插入到t表中，完全满足刚才的需求，不过这种写法大家可能略感陌生，结果却是对的。现在我们执行如下：

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

SQL> insert into t select rownum from dual connect by level<=100000;

已创建100000行。

已用时间: 00: 00: 00.25

SQL> commit;

提交完成。

已用时间: 00: 00: 00.00

SQL> select count(*) from t;

COUNT(*)

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

100000

脚本2-39 第5次用集合写法后0.22秒完成，动车变飞机

大家认真看看完成的时间吧。”梁老师得意地回过头望着大家。

“0.25秒！”这次不再是晶晶一人的声音了，是全部同学一起喊起来了。

“每秒插入40万条，太快了吧！”小莲再次喊出声来。

“为什么会快这么多呢？其实是因为原先的过程变成了SQL，一条一条插入的语句变成了一个集合的概念，变成了一整批地写进DATA BUFFER区里，好比你要运砖头到目的地，一种是一块砖头拿到目的地，再返回拿第二块，直到拿完全部。而另一种是全部放在板车一起推至目的地，只是这里的目的地是DATA BUFFER区而已。

听明白了吗？”

“听明白了！”大家都很激动，梁老师真像一个魔术师。

“听明白就好，现在你们该好好想想请老师晚上去哪里吃饭了。”

同学们都乐了，大家心里都知道梁老师是在开玩笑。

2.3.2.6 直接路径，火箭速度

“没声音啊，看来大家怕花钱啊，要不老师再给同学们一个机会，如果我还能让这个插入语句更快，大家就请客，否则老师请客，如何？”

梁老师有完没完啊，都每秒钟40万条的速度了，还想快，疯了吧。同学们议论纷纷。

“那我开始了，因为前面完成时间都已经到零点几秒了，太小会有误差，所以我准备把数据量放大100倍，10万条改为插入1000万条，前面飞机速度的语句变成如下：

SQL> connect ljb/ljb

已连接。

SQL> drop table t purge;

表已删除。

SQL> create table t ( x int );

表已创建。

SQL> alter system flush shared_pool;

系统已更改。

SQL> set timing on

SQL> insert into t select rownum from dual connect by level<=10000000;

已创建10000000行。

已用时间: 00: 00: 23.22

SQL> commit;

脚本2-40 试验准备，将集合写法的试验数据量放大100倍

发现插入1000万条记录完成的时间是23秒多，大致为每秒钟43万条记录，和插入10万条记录时的速度每秒40万条大体接近，下面我们改用create table 的直接路径方式来新建t表，看看这样的方法速度能否有提升。

SQL> drop table t purge;

表已删除。

已用时间: 00: 00: 11.07

SQL> alter system flush shared_pool;

系统已更改。

已用时间: 00: 00: 00.02

SQL> set timing on

SQL> create table t as select rownum x from dual connect by level<=10000000;

表已创建。

已用时间: 00: 00: 10.14

脚本2-41 第6次改进，直接路径让飞机变火箭

测试结果是，速度又有了2倍多的提升，只需要10秒即可完成，等同于插入速度为每秒钟100万条，要不是亲眼所见，还真不敢相信吧。

同学们知道这是为什么吗？真正的原因在于，insert into t select ……的方式是将数据先写到DATA BUFFER中，然后再刷到磁盘中。而create table t 的方式却是跳过了数据缓存区，直接写进磁盘中，这种方式又称之为直接路径读写方式，因为原本是数据先到内存，再到磁盘，更改为直接到磁盘，少了一个步骤，因而速度提升了许多。

直接路径读写方式的缺点在于由于数据不经过数据缓存区，所以在数据缓存区中一定读不到这些数据，因此一定会有物理读。但是在很多时候，尤其是海量数据需要迁移插入时，快速插入才是真正的第一目的，该表一般记录巨大，DATA BUFFER甚至还装不下其十分之一、百分之一，这些共享的数据意义也不大，这时，我们一般会选择直接路径读写的方式来完成海量数据的插入。

同学们，听明白了没，现在大家甘心请客了吧？”梁老师时刻不忘调侃。

台下都听呆住了，梁老师这堂课真是神了，大家半天没回过神来。

2.3.2.7 并行设置，飞船速度

“大家这次请客是请定了，具体时间老师通知哦。”

台下哈哈大笑，大家还是回过神来了，今天这堂课给梁老师弄得一愣一愣的。

“同学们，插入语句还能再快吗？”

这下台下同学们都不敢应答了，梁老师没完没了，却每次都能不断加速，而且用到的知识又和体系知识息息相关，让自己一听就明白了。可以看出梁老师这个经典案例的例子是精心构造的，真可以说是经典中的经典。

“看来是被我给忽悠住了，大家都不敢应了。”梁老师笑着说道，“其实遇到性能好的机器，还是可以大幅度提升性能的，大家看如下语句，我设置日志关闭nologging，并且设置parallel 16 表示用到机器的16个CPU，结果在笔记本环境收效不是很明显，因为我的环境是单核的机器。

后来我把如下SQL运行在强劲的服务器上，有16个CPU，下面的语句仅仅在4秒不到的时间内就完成了，速度相对于前面的火箭速度而言，快多了，几乎是每秒钟300万条的插入速度，具体如下：

drop table t purge;

alter system flush shared_pool;

set timing on

create table t nologging parallel 64

as select rownum x from dual connect by level<=10000000;

脚本2-42 第7次改进，并行原理让火箭变飞船

不过并行最大的特点就是占用了大多数CPU的资源，如果是一个并发环境，很多应用在跑，因为这个影响了别的应用，导致别的应用资源不足，将引发很多严重问题，所以需要三思而后行，了解清楚该机器是否允许你这样占用全部的资源。

好了，今天我以一条最简单的插入顺序数字进某表的SQL语句为例，方法从存储过程实现到仅用单条SQL完成；速度从原先的每秒2千多条提升到每秒300万条，这中间都做了哪些改进呢，是否都和体系结构有关呢？

希望大家好好复习这一节的经典案例，回忆一下速度的6次飞跃之旅，好好感受一下灵活应用知识的无限魅力。”

作者简介

梁敬彬，网名wabjtam123，任ITPUB版主、ITPUB社区专家、福建富士通公司数据库专家。参与编写过《剑破冰山——Oracle开发艺术》、《DBA手记2》等技术书籍，多年从事电信相关行业工作，负责系统架构设计、优化、培训等工作，有着丰富的数据库管理、设计、开发、培训经验和电信行业经验。

梁敬弘，清华大学计算机系博士毕业，在计算机领域和金融领域皆有建树，拥有多项计算机相关核心专利技术的同时还拥有金融行业的CFP等高级认证。现就职于华夏银行总行。

媒体评论

我在ITPUB认识梁敬彬先生始，就拜读他当时参与的大作《剑破冰山——Oracle开发艺术》，直至今天，这本书里的部分内容在行业里还发挥着重要影响力。从事数据库事业多年，读过无数的技术书，有洋洋万言的，有短小精悍的，但大多写得正儿八经，有距离感，还有点冷。梁敬彬先生的新书，用生动的故事形式叙述复杂技术，开创数据库技术书籍故事化的写作先河。梁先生技术功底和文字功底同样深厚，更重要的是具有作为讲师那种缜密、体系化的思维方式，以及对读者心思的透视力，因此成书脉络清晰，里面还不断穿插许多人生哲理，技术前瞻，让人获益良多。这本书非常适合入行者和在行业里谋求上升的同仁阅读，动人的文笔可以让你一口气读完这本书，而且完全没有读其它技术书籍时那种头晕脑胀，昏昏入睡的感觉。这是一本值得向行业推介的优秀技术书籍。

黄志洪(tigerfish) www.dataguru.cn

中国数据库社区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管理版资深版主

前言

别出心裁另出蹊径

——与梁敬彬先生序

敬彬的新书就要出版，邀我写一点感受，于是就有了这一段文字。

我和敬彬相识是在2010年，那时我正在编辑《Oracle DBA手记》一书，偶然被他发表在ITPUB论坛上的一篇文章所吸引，那篇文章的题目是《DBA 小故事之SQL诊断》，其内容清晰、行文引人，于是就和他约了那篇稿子加入到书中，期间邮件往来再到北京会面，就此熟识。

从当时的一篇文章到今天的一本书，我能够清晰地看到作者一以贯之的思考和叙述方式，这种积累与坚持也正是作者成长和成功的要素之一。

当时那篇文章的感受和今天这本书是类似的，作者能够用曲折的笔触将自己的经历真实生动地再现出来，并且带领读者一起经历一次思维的探索，这是属于他的独特风格。

作者在书中反复传达的核心观点是：Oracle数据库看似艰深的原理实际上和生活中的基本常识并无二致。理解了这一层意思，就能够克服对于这门技艺的畏惧之心，此后的学习自然就能够顺风顺水。

诚然如此，我也经常和朋友们说，对于Oracle的很多艰深算法，如果由我们去深思熟虑，其结果都必然大致相同。类似HASH原理，布隆过滤等算法，理解了你就只觉得巧妙而不觉艰深。