登入帳戶  | 訂單查詢  | 購物車/收銀台( 0 ) | 在線留言板  | 付款方式  | 聯絡我們  | 運費計算  | 幫助中心 |  加入書簽
會員登入 新註冊 | 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌 香港/國際用戶
最新/最熱/最齊全的簡體書網 品種:超過100萬種書,正品正价,放心網購,悭钱省心 送貨:速遞 / EMS,時效:出貨後2-3日

2024年04月出版新書

2024年03月出版新書

2024年02月出版新書

2024年01月出版新書

2023年12月出版新書

2023年11月出版新書

2023年10月出版新書

2023年09月出版新書

2023年08月出版新書

2023年07月出版新書

2023年06月出版新書

2023年05月出版新書

2023年04月出版新書

2023年03月出版新書

『簡體書』收获,不止Oracle(顶级专家盖国强、冯春培、黄志洪等联袂力荐)

書城自編碼: 2053680
分類: 簡體書→大陸圖書→計算機/網絡數據庫
作者: 梁敬彬
國際書號(ISBN): 9787121200700
出版社: 电子工业出版社
出版日期: 2013-05-01
版次: 1 印次: 1
頁數/字數: 472/750000
書度/開本: 16开 釘裝: 平装

售價:NT$ 549

我要買

share:

** 我創建的書架 **
未登入.



新書推薦:
墓志的生成及其在唐代的衍变研究
《 墓志的生成及其在唐代的衍变研究 》

售價:NT$ 549.0
理解中国经济:在大变局中读懂新机遇
《 理解中国经济:在大变局中读懂新机遇 》

售價:NT$ 252.0
饥饿与国家:苏丹的饥荒、奴隶制和权力(1883~1956)
《 饥饿与国家:苏丹的饥荒、奴隶制和权力(1883~1956) 》

售價:NT$ 386.0
管好你的钱:人人都要懂的财富传承(一本书带你了解财富传承的7种方式)
《 管好你的钱:人人都要懂的财富传承(一本书带你了解财富传承的7种方式) 》

售價:NT$ 381.0
新质生产力:中国创新发展的着力点与内在逻辑
《 新质生产力:中国创新发展的着力点与内在逻辑 》

售價:NT$ 442.0
“漫画强国科技”系列(全4册)
《 “漫画强国科技”系列(全4册) 》

售價:NT$ 784.0
打破社交媒体棱镜:探寻网络政治极化的根源
《 打破社交媒体棱镜:探寻网络政治极化的根源 》

售價:NT$ 325.0
那一抹嫣红
《 那一抹嫣红 》

售價:NT$ 330.0

建議一齊購買:

+

NT$ 1152
《 基于Oracle的SQL优化(社区万众期待,数据库优化扛鼎巨著) 》
+

NT$ 568
《 Oracle 从入门到精通(附光盘1张) 》
+

NT$ 1036
《 Oracle Database 9i/10g/11g编程艺术:深入数据库体系结构(第2版)(世界顶级专家Thomas Kyte力作) 》
+

NT$ 656
《 剑破冰山——Oracle开发艺术 》
編輯推薦:
颠覆IT技术图书的传统写作方式,在妙趣横生的故事中学到Oracle核心知识与优化方法论,让你摆脱技术束缚,超越技术。
內容簡介:
在《收获,不止Oracle》这本书里读者将会跟随作者一同对Oracle数据库的相关知识进行梳理,最终共同提炼出必须最先掌握的那部分知识,无论你是数据库开发、管理、优化、设计人员,还是从事Java、C的开发人员。接下来作者再将这部分知识中最实用的内容进一步提炼,浓缩出最精华的部分,分享给大家。这是二八现象的一次经典应用。
这部分知识就是Oracle的物理体系结构、逻辑体系结构、表、索引以及表连接五大部分。通过阅读这些章节,读者将会在最短时间内以一种有史以来最轻松的方式,完成对Oracle数据库的整体认识,不仅能在工作中解决常规问题,还能具备一定的设计和调优能力。相信通过这些章节的学习,会给读者的Oracle学习带来极大的收获。
然而,作者最希望看到的是:让读者的收获,不止Oracle。
为达到此目的,作者精心将全书分成了上下两篇,刚才所描述的具体知识点体现在全书的上篇,而在下篇中,读者将通过各种精彩故事、生动案例,体会到该如何学习和如何思考,在意识的天空抛开束缚,无拘无束、尽情飞翔。
在这里,读者也许会有疑问,前面说的有史以来最轻松的方式是一种什么样的方式呢?还请亲爱的读者自己去揭晓谜底吧。
關於作者:
梁敬彬,网名wabjtam123,任ITPUB版主、ITPUB社区专家、福建富士通公司数据库专家。参与编写过《剑破冰山--Oracle开发艺术》、《DBA手记2》等技术书籍,多年从事电信相关行业工作,负责系统架构设计、优化、培训等工作,有着丰富的数据库管理、设计、开发、培训经验和电信行业经验。
梁敬弘,清华大学计算机系博士毕业,在计算机领域和金融领域皆有建树,拥有多项计算机相关核心专利技术的同时还拥有金融行业的CFP等高级认证。现就职于华夏银行总行。
目錄
上篇 开启惊喜之门--带意识地学Oracle
第1章 意识,少做事从学习开始
1.1 选择先学什么颇有学问
1.1.1 梁老师课堂爆笑开场
1.1.2 看似跑题的手机分类
1.1.3 学什么先了解做什么
1.2 善于规划分类才有效果
1.2.1 分类与角色密切相关
1.2.2 角色自我认识有讲究
1.3 明白学以致用方有意义
第2章 震惊,体验物理体系之旅
2.1 必须提及的系列知识
2.2 物理体系从老余开店慢慢铺开
2.2.1 老余的三个小故事
2.2.1.1 顾客的尺寸
2.2.1.2 有效的调整
2.2.1.3 记录的习惯
2.2.2 体系结构原理初探
2.2.2.1 从一普通查询SQL说起
2.2.2.2 老余故事终现用心良苦
2.2.2.3 一起体会Oracle代价
2.2.3 体系结构原理再探
2.2.3.1 从一普通更新语句说起
2.2.3.2 体系结构中提交的探讨
2.2.3.3 劳模的评选
2.2.3.4 回滚的研究
2.2.3.5 一致的查询
2.2.3.6 一致读的原理
2.2.3.7 实践的体会
2.3 体系学习让SQL性能提升千倍
2.3.1 一起探索体系学习的意义
2.3.1.1 同学们不知所学何用
2.3.1.2 实际上大有用武之地
2.3.2 单车到飞船的经典之旅
2.3.2.1 未优化前,单车速度
2.3.2.2 绑定变量,摩托速度
2.3.2.3 静态改写,汽车速度
2.3.2.4 批量提交,动车速度
2.3.2.5 集合写法,飞机速度
2.3.2.6 直接路径,火箭速度
2.3.2.7 并行设置,飞船速度
2.3.3 精彩的总结与课程展望
2.3.3.1 最大的收获应该是思想
2.3.3.2 老师的课程展望与规划
第3章 神奇,走进逻辑体系世界
3.1 长幼有序的逻辑体系
3.2 逻辑体系从老余养殖细细说起
3.2.1 农场之体系逻辑结构
3.2.2 农场之 BLOCK 漫谈
3.2.3 农场之区与段
3.2.4 农场之表空间的分类
3.2.4.1 表空间与系统农场
3.2.4.2 表空间与临时农场
3.2.4.3 表空间与回滚农场
3.2.5 逻辑结构之初次体会
3.2.5.1 逻辑结构之 BLOCK
3.2.5.2 逻辑结构之 TABLESPACE
3.2.5.3 逻辑结构之 USER
3.2.5.4 逻辑结构之 EXTENT
3.2.5.5 逻辑结构之 SEGMENT
3.2.6 逻辑结构之二次体会
3.2.6.1 BLOCK的大小与调整
3.2.6.2 PCTFREE参数与调整
3.2.6.3 PCTFREE与生效范围
3.2.6.4 EXTENT 尺寸与调整
3.2.7 逻辑结构之三次体会
3.2.7.1 已用与未用表空间情况
3.2.7.2 表空间大小与自动扩展
3.2.7.3 回滚表空间新建与切换
3.2.7.4 临时表空间新建与切换
3.2.7.5 临时表空间组及其妙用
3.3 课程结束你给程序安上了翅膀
3.3.1 过度扩展与性能
3.3.2 PCTFREE与性能
3.3.3 行迁移与优化
3.3.4 块的大小与应用
第4章 祝贺,表的设计成就英雄
4.1 表的设计之五朵金花
4.2 表的特性从老余一家展开描述
4.2.1 老余一家各施所长
4.2.2 普通堆表不足之处
4.2.2.1 表更新日志开销较大
4.2.2.2 delete无法释放空间
4.2.2.3 表记录太大检索较慢
4.2.2.4 索引回表读开销很大
4.2.2.5 有序插入却难有序读出
4.2.3 奇特的全局临时表
4.2.3.1 分析全局临时表的类型
4.2.3.2 观察各类DML的REDO量
4.2.3.3 全局临时表两大重要特性
4.2.4 神通广大的分区表
4.2.4.1 分区表类型及原理
4.2.4.2 分区表最实用的特性
4.2.4.3 分区索引类型简述
4.2.4.4 分区表之相关陷阱
4.2.5 有趣的索引组织表
4.2.6 簇表的介绍及应用
4.3 理解表设计的你成为项目组英雄
第5章 惊叹,索引天地妙不可言
5.1 看似简单无趣的索引知识
5.2 索引探秘从小余缉凶拉开帷幕
5.2.1 BTREE索引的精彩世界
5.2.1.1 BTREE索引结构图展现
5.2.1.2 到底是物理还是逻辑结构
5.2.1.3 索引结构三大重要特点
5.2.1.4 插播小余缉凶精彩故事
5.2.1.5 妙用三特征之高度较低
5.2.1.6 巧用三特征之存储列值
5.2.1.7 活用三特征之索引有序
5.2.1.8 不可不说的主外键设计
5.2.1.9 组合索引高效设计要领
5.2.1.10 变换角度看索引的危害
5.2.1.11 如何合理控制索引数量
5.2.2 位图索引的玫瑰花之刺
5.2.2.1 统计条数奋勇夺冠
5.2.2.2 即席查询一骑绝尘
5.2.2.3 遭遇更新苦不堪言
5.2.2.4 重复度低一败涂地
5.2.2.5 了解结构真相大白
5.2.3 小心函数索引步步陷阱
5.2.3.1 列运算让索引失去作用
5.2.3.2 函数索引是这样应用的
5.2.3.3 避免列运算的经典案例
5.3 索引让一系列最熟悉的SQL飞起来了
第6章 经典,表的连接学以致用
6.1 表的连接之江南三剑客
6.2 三大类型从小余跳舞一一道来
6.2.1 跳舞也能跳出连接类型
6.2.1.1 感觉怪异的嵌套循环
6.2.1.2 排序合并及哈希连接
6.2.2 各类连接访问次数差异
6.2.2.1 嵌套循环的表访问次数
6.2.2.2 哈希连接的表访问次数
6.2.2.3 排序合并的表访问次数
6.2.3 各类连接驱动顺序区别
6.2.3.1 嵌套循环的表驱动顺序
6.2.3.2 哈希连接的表驱动顺序
6.2.3.3 排序合并的表驱动顺序
6.2.4 各类连接排序情况分析
6.2.4.1 除嵌套循环都需排序
6.2.4.2 排序只需取部分字段
6.2.4.3 关于排序的经典案例
6.2.5 各类连接限制场景对比
6.2.5.1 哈希连接的限制
6.2.5.2 排序合并的限制
6.2.5.3 嵌套循环无限制
6.3 你动手装备的表连接威震三军
6.3.1 嵌套循环与索引
6.3.2 哈希连接与索引
6.3.3 排序合并与索引
下篇 飞翔意识天空--思想与案例的分享
第7章 搞定!不靠技术靠菜刀
7.1 SQL被一刀剁了
7.2 整个模块丢弃了
7.3 调用次数减少了
7.4 排序不再需要了
7.5 大表砍成小表了
7.6 排重操作消失了
7.7 插入阻碍小多了
7.8 迁移事情不做了
第8章 升级!靠技术改隐形刀
8.1 大表等同小表了
8.2 大表切成小表了
8.3 索引变身小表了
8.4 删除动作不做了
8.5 清表角度变换了
8.6 提交次数缩减了
8.7 迁移越来越快了
8.8 SQL语句精简了
第9章 提问,也是智慧的体现
9.1 描述要考虑周全
9.2 用词要尽量准确
9.3 说明要力求简洁
9.4 问过的避免再问
9.5 能搜能试不急问
第10章 买鱼,居然买出方法论
10.1 小余买鱼系列故事
10.1.1 诊断与改进
10.1.2 需求与设计
10.1.3 资源的利用
10.1.4 真正的需求
10.2 买鱼买出了方法论
10.2.1 一套流程
10.2.2 两大法宝
10.3 方法论的应用案例
10.3.1 从我们的这一套流程说起
10.3.1.1 诊断
10.3.1.2 改进优化(首次优化)
10.3.1.3 需求与设计(再次优化)
10.3.1.4 资源利用(花絮)
10.3.2 案例映衬了经典两大法宝
第11章 宝典,规范让你少做事
11.1 抓狂,为何事总忙不完
11.1.1 技术能力不足的新人们
11.1.2 不懂提问智慧的求助者
11.1.3 产生各种失误的粗心者
11.1.3.1 啊,小黄的DDL惹祸
11.1.3.2 惨,老师登错环境了
11.1.3.3 糟,小罗忘操作……
11.1.4 解决问题缓慢的技术员
11.1.4.1 优化效率低下的小高
11.1.4.2 为何老师能快速解决
11.1.5 陷入种种困境的开发者
11.1.5.1 超长SQL使小郑烦恼
11.1.5.2 缺少注释让小叶沮丧
11.1.6 总是考虑不全的设计者
11.1.6.1 未提前规划的王工
11.1.6.2 不了解特性的刘工
11.2 淡定,规范少做无谓事
11.2.1 学习规范--促成新人快速成长
11.2.2 求助规范--引导求助不再迷糊
11.2.3 操作规范--协助粗心者不犯错
11.2.4 流程规范--保障问题快速解决
11.2.4.1 动态整体
11.2.4.2 动态局部
11.2.4.3 静态整体
11.2.4.4 静态局部
11.2.5 开发规范--让开发者驾轻就熟
11.2.5.1 SQL编写规范
11.2.5.2 PLSQL编写规范
11.2.6 设计规范--助设计者运筹帷幄
11.2.6.1 表规范
11.2.6.2 索引规范
11.2.6.3 环境参数规范
11.2.6.4 命名规范
內容試閱
2.3.2 单车到飞船的经典之旅
“刚才老师回答了不少同学的疑问,说明了学习体系结构还是有意义的。看来只要善于思考,善于联系,我们就能很容易地应用所学的知识解决遇到的问题。
现在我给大家讲一个具体的案例,通过执行系列等价SQL语句的性能差异,来分析其中的原因所在。
2.3.2.1 未优化前,单车速度
首先构造环境,保证下列语句执行过了,t表已经存在:

sqlplus ljbljb
drop table t purge;
create table t x int ;
--将共享池清空
alter system flush shared_pool;
脚本2-29 单车到飞船试验前的准备工作
有一个开发人员写了类似如下的一个简单存储过程,实现了将1到10万的值插入t表的需求,具体如下:

create or replace procedure proc1
as
begin
for i in 1 .. 100000
loop
execute
immediate
''insert into t values
''||i||'''';
commit;
end loop;
end;

----这里要记得先预先执行一遍,将过程创建起来!
脚本2-30 单车到飞船试验前构造proc1
该语句从需求实现上没有任何问题,我们执行如下:

SQL connect ljbljb
已连接。
SQL drop table t purge;
表已删除。
SQL create table t x int ;
表已创建。
SQL alter system flush shared_pool;
系统已更改。
SQL set timing on
SQL exec proc1 ;
PLSQL 过程已成功完成。
已用时间: 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在PLSQL
DEVELOPER工具中查询(这个工具有着很友好的界面,尤其适合数据库开发人员使用,因此除了介绍先前的sqlplus
工具外,这里也顺道提一下这个PLSQL
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
as
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;
PLSQL 过程已成功完成。
已用时间: 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
as
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;
PLSQL 过程已成功完成。
已用时间: 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
as
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;
PLSQL 过程已成功完成。
已用时间: 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 ljbljb
已连接。
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次飞跃之旅,好好感受一下灵活应用知识的无限魅力。”

 

 

書城介紹  | 合作申請 | 索要書目  | 新手入門 | 聯絡方式  | 幫助中心 | 找書說明  | 送貨方式 | 付款方式 香港用户  | 台灣用户 | 海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 (香港)大書城有限公司 All Rights Reserved.