收获，不止SQL优化--抓住SQL的本质

2.1.3　未能明确需求目标白费劲 26
2.1.4　没有分析操作难度乱调优 26
2.2　如何缩短SQL调优时间 27
2.2.1　先获取有助调优的数据库整体信息 27
2.2.2　快速获取SQL运行台前信息 27
2.2.3　快速拿到SQL关联幕后信息 28
2.3　从案例看快速SQL调优 29
2.3.1　获取数据库整体的运行情况 29
2.3.2　获取SQL的各种详细信息 29
2.4　本章总结延伸与习题 32
2.4.1　总结延伸 32
2.4.2　习题训练 33
第3章　循规蹈矩--如何读懂SQL执行计划 34
3.1　执行计划分析概述 35
3.1.1　SQL执行计划是什么 35
3.1.2　统计信息用来做什么 36
3.1.3　数据库统计信息的收集 37
3.1.4　数据库的动态采样 37
3.1.5　获取执行计划的方法（6种武器） 40
3.2　读懂执行计划的关键 48
3.2.1　解释经典执行计划方法 49
3.2.2　总结说明 55
3.3　从案例辨别低效SQL 55
3.3.1　从执行计划读出效率 56
3.3.2　执行计划效率总结 60
3.4　本章习题、总结与延伸 60
第4章　运筹帷幄--左右SQL执行计划妙招 62
4.1　控制执行计划的方法综述 63
4.1.1　控制执行计划的意义 63
4.1.2　控制执行计划的思路 64
4.2　从案例探索其方法及意义 65
4.2.1　HINT的思路 65
4.2.2　非HINT方式的执行计划改变 72
4.2.3　执行计划的固定 100
4.3　本章习题、总结与延伸 102
第5章　且慢，感受体系结构让SQL飞 103
5.1　体系结构知识 104
5.1.1　组成 104
5.1.2　原理 104
5.1.3　体会 105
5.2　体系与SQL优化 106
5.2.1　与共享池相关 107
5.2.2　数据缓冲相关 111
5.2.3　日志归档相关 116
5.3　扩展优化案例 118
5.3.1　与共享池相关 118
5.3.2　数据缓冲相关 122
5.3.3　日志归档相关 126
5.4　本章习题、总结与延伸 130
第6章　且慢，体验逻辑结构让SQL飞 132
6.1　逻辑结构 132
6.2　体系细节与SQL优化 133
6.2.1　Block 133
6.2.2　Segment与extent 137
6.2.3　Tablespace 139
6.2.4　rowid 139
6.3　相关优化案例分析 140
6.3.1　块的相关案例 141
6.3.2　段的相关案例 144
6.3.3　表空间的案例 148
6.3.4　rowid 151
6.4　本章习题、总结与延伸 153
第7章　且慢，探寻表的设计让SQL飞 154
7.1　表设计 154
7.1.1　表的设计 155
7.1.2　其他补充 155
7.2　表设计与SQL优化 156
7.2.1　表的设计 156
7.2.2　其他补充 179
7.3　相关优化案例分析 184
7.3.1　分区表相关案例 185
7.3.2　全局临时表案例 190
7.3.3　监控异常的表设计 195
7.3.4　表设计优化相关案例总结 199
7.4　本章习题、总结与延伸 199
第8章　且慢，学习索引如何让SQL飞 200
8.1　索引知识要点概述 201
8.1.1　索引结构的推理 201
8.1.2　索引特性的提炼 204
8.2　索引的SQL优化 206
8.2.1　经典三大特性 207
8.2.2　组合索引选用 217
8.2.3　索引扫描类型的分类与构造 219
8.3　索引相关优化案例 225
8.3.1　三大特性的相关案例 225
8.3.2　组合索引的经典案例 231
8.4　本章习题、总结与延伸 234
第9章　且慢，弄清索引之阻碍让SQL飞 235
9.1　索引的不足之处 235
9.1.1　索引的各种开销 236
9.1.2　索引使用失效 236
9.2　感受美好索引另一面 237
9.2.1　索引各种开销 237
9.2.2　索引使用失效 243
9.2.3　索引取舍控制 246
9.3　从案例看索引各种恨 248
9.3.1　索引的开销 248
9.3.2　索引去哪儿了 253
9.3.3　索引的取舍 267
9.4　本章习题、总结与延伸 269
第10章　且慢，其他索引应用让SQL飞 270
10.1　其他索引的总体概述 270
10.1.1　位图索引 271
10.1.2　函数索引 271
10.1.3　反向键索引 272
10.1.4　全文索引 272
10.2　走进其他索引的世界 272
10.2.1　位图索引 273
10.2.2　函数索引 278
10.2.3　反向键索引 282
10.2.4　全文索引 282
10.3　其他索引的相关案例 285
10.3.1　位图索引 286
10.3.2　函数索引 288
10.3.3　反向键索引 297
10.3.4　全文索引 299
10.4　本章习题、总结与延伸 300
第11章　且慢，表连接的秘密让SQL飞 302
11.1　三大经典表连接概要说明 302
11.2　各类型表连接的知识要点 303
11.2.1　从表的访问次数探索 304
11.2.2　表驱动顺序与性能 308
11.2.3　表连接是否有排序 311
11.2.4　各连接的使用限制 314
11.2.5　三大表连接的特性总结 317
11.3　从案例学表连接优化要点 （三刀三斧四式走天下） 317
11.3.1　一次Nested Loops Join的优化全过程 318
11.3.2　一次Hash Join 的 优化全过程 320
11.3.3　一次 Merge Sort Join 的优化全过程 324
11.3.4　一次统计信息收集不准确引发的NL性能瓶颈 329
11.4　本章习题、总结与延伸 332
第12章　动手，经典等价改写让SQL飞 333
12.1　设法减少访问路径 333
12.1.1　Case When改造 334
12.1.2　Rownum分页改写 337
12.1.3　Hint直接路径改造 338
12.1.4　只取你所需的列 339
12.1.5　避免或者减少递归调用 341
12.1.6　ROWID优化应用 347
12.2　设法避免外因影响 350
12.2.1　Hint改写确保执行计划正确 350
12.2.2　避免子查询的错误执行计划 350
12.2.3　所在环境的资源不足等问题 351
12.3　本章习题、总结与延伸 351
第13章　动手，过程函数优化让SQL飞 352
13.1　PL/SQL优化重点 353
13.1.1　定义类型的优化 353
13.1.2　PL/SQL的集合优化 355
13.1.3　PL/SQL的游标合并 361
13.1.4　动态SQL 364
13.1.5　使用10046 trace跟踪PL/SQL 368
13.2　PL/SQL优化其他相关扩展 369
13.2.1　编译无法成功 369
13.2.2　通用脚本分享 370
13.3　本章习题、总结与延伸 380
第14章　动手，高级写法应用让SQL飞 381
14.1　具体SQL调优思路 381
14.1.1　改写SQL调优 382
14.1.2　不改写SQL调优 382
14.2　高级SQL介绍与案例 383
14.2.1　GOURP BY的扩展 383
14.2.2　INSERT ALL 389
14.2.3　MERGE 392
14.2.4　WITH子句 402
14.3　本章习题、总结与延伸 404
第15章　动手，分析函数让SQL飞 406
15.1　高级SQL之分析函数 407
15.1.1　语法概述 407
15.1.2　特别之处 407
15.2　分析函数详解与案例 409
15.2.1　学习详解 410
15.2.2　案例分享 417
15.3　本章习题、总结与延伸 432
第16章　动手，把握需求改写让SQL飞 433
16.1　考虑需求最小化 434
16.2　千万弄清SQL改造的等价性 434
16.2.1　看似等价的写法，其实不等价 435
16.2.2　看似不等价的写法，其实等价 438
16.3　开发设计应用中的需求 439
16.3.1　界面权限设计优化 439
16.3.2　界面汇总与展现 439
16.3.3　界面实时刷新改良 439
16.3.4　目录树菜单的优化 440
16.4　场景选择的经典案例之谁是Count(*)之王 440
16.4.1　优化过程 440
16.4.2　优化总结 445
16.5　本章习题、总结与延伸 446
第17章 总结与延伸：从勿信讹传到洞若观火 447
17.1　SQL优化的各个误区 447
17.1.1　COUNT(*)与COUNT(列)的传言 447
17.1.2　谈SQL编写顺序之流言蜚语 451
17.1.3　IN与EXISTS之争 455
17.1.4　总结探讨 457
17.2　误区背后的话题扩展 457
17.2.1　话题扩展之等价与否优先 457
17.2.2　话题扩展之颠覆误区观点 458
17.3　全书完，致读者 461

.　　真是如此吗？好吧，以IT学习中的SQL优化为例，你知道如何进行学习吗？
　　这个我知道，SQL优化主要是看执行计划，比如发现是不合理的全表扫描，就设法转成索引扫描等。
　　说得有点简单啊。其实SQL本不需要优化，就是因为前面我们所说的当今IT系统复杂度高、访问量和并发量都大，而数据又是IT应用中访问的热点，因此这些压力自然就体现在IT系统对应的数据库模块上，所以SQL需要优化。
　　哦，原来如此，明白了。
　　任何IT系统，数据都是核心，同时也是访问和展现的热点，脱离数据库的IT项目几乎不存在，甚至可以说几乎没有不需要进行数据库操作的编程人员，而能与数据库进行无缝交互的就只有SQL了。此外，SQL是一种学起来非常容易的"傻瓜语言"，随便一个where条件就是一个需求实现，基本上新手级别的开发人员坐下来看看简单语法即可编写SQL，如果有3天时间边做边学，基本上所有SQL都会编写了。用我本人的例子来说吧，有人忽然问我学SQL开发学了多久，我几乎是本能般从嘴里冒出一句：SQL开发，我有花时间学吗，写SQL难道不是自然而然就会了吗？
　　正因为SQL如此重要，学习成本又如此之低，同时与IT系统中不可或缺的数据库交互起来浑然天成，所以几乎所有Java、C等开发人员都能较熟练应用数据库SQL开发技术。这导致应用SQL开发的人在数量上异常庞大，简单地说，就是所有前后端程序开发人员和IT运维人员以及数据库开发人员的总和！
　　于是在高访问量、高并发的IT系统数据库模块中，平均每秒运行成千上万条SQL的场景已成常态。在这种情况下，这些SQL如果运行较慢，便容易迅速拖垮整个IT系统，因此SQL优化就变得特别重要了。此外，由于SQL过多，不可能仅靠一两个SQL专家筋疲力尽地调优，我们便可以高枕无忧了。最有效的方式是，每个SQL编写人员自己要有SQL优化的意识和本领！
　　老师，我在项目组里做Java开发，确实也涉及大量的SQL开发，您说得没错，我也感觉SQL开发特简单，不过我的SQL经常跑得很慢，您说SQL优化好学吗？
　　结论：数据是IT系统的核心、重中之重，而SQL是数据交互的必然手段，所以SQL的应用非常广泛，使用人群数量也非常庞大，因此SQL的重要性不言而喻！
　　涌SQL之优化泪水
　　SQL优化肯定比SQL编写本身要难很多，但也存在一些优化的基础知识，如SQL执行计划、索引原理，等等。这些都比编写SQL本身要复杂得多，因此要成为SQL优化高手仅知道一些优化基础知识是远远不够的，还需要经验的沉淀，并且要转化成你的方法论。
　　老师，您能否举例说明一下需要什么经验吗？
　　不妨我回答得更有趣点吧，先给你说几个SQL优化的小故事，其中奥妙我们后续探讨。
　　太好了！
　　嗯，你边听边思考。故事1：话说某天上午小王被告知某系统的一个菜单访问非常慢，于是他开始介入优化，他跟踪到该菜单调用的具体SQL，接下来他通过观察该SQL的执行计划发现该SQL访问某张表时没走索引，觉得该表应该加一个索引，他花了整整1个小时发现这个问题后非常兴奋，于是马上动手开始建索引了。建索引大概花费了几分钟时间，随后他发现SQL走索引了，并且真的快了许多。于是测试一下该菜单，果然快了不少。故事1讲完了。
　　啥，讲完了，太短了吧，您这说的是优化成功案例吗？
　　是否成功一会儿再下结论，接下来说故事2。话说小王优化效果杠杠的，正自鸣得意时，被告知虽然这个菜单变快了，不过刚才持续几分钟时间出现访问该菜单一直报错的情况，随后正常。
　　老师，这啥意思，为啥应用程序会出错，怎么就恢复了？您故事2讲完了吗，怎么您的故事都这么短啊？
　　嗯，现在开始说第3个故事了。当天下午小王又接到电话，被告知那菜单访问又慢了。小王有点吃惊，于是赶紧登录系统运行该SQL，发现确实变慢了，不过奇怪的是该SQL正常走索引，没什么问题啊，小王很是郁闷。正在他束手无策之时，小王又接到电话，说该菜单又快了。晕，他现在可是啥都没做，这是咋回事？当晚，小王辗转反侧，无心睡眠。第2天小王又接到电话……他崩溃了。
　　好可怜啊。然后呢？
　　继续第4个故事。话说小王崩溃之后无法正常工作，于是领导把这难题交给其他人处理了，小王得知后满血复活再度投入工作中。几天后小王又迎来一个新任务，开发项目组中有一条SQL很慢，希望能优化一下。小王看了一眼觉得写得歪瓜裂枣样很不舒服，于是挽起袖子对SQL进行重写，改改改！
　　然后呢？
　　小王改好后，满怀期待的开发组对新的SQL一运行，发现跑得比之前的SQL还要慢很多！
　　可怜，小王又崩溃了吧，接下来呢？
　　嗯，说故事5吧。在小王再度崩溃之前，公司的SQL优化大师老丁正好路过，他分析了之后，建议将SQL语句涉及的某表的外键加上索引。后来大家照办了，果然性能迅速提升！老丁告诉小王，优化前可通过各种手段先观察观察SQL涉及的表结构、索引等，看它们有无不合理之处，急于动手改造SQL太盲目了，是没有抓住主要矛盾的体现，而且改代码需要测试、打补丁、上线，也是一件很辛苦的事。小王频频点头，谨记老丁教诲。
　　看来小王成长了。
　　是吗？那我们继续说故事6。
　　一周后小王又面对一条SQL需要优化，这次他不动手改写了，尝试了加索引，又尝试了调整表结构，结果提升效果非常不明显……
　　然后呢，又崩溃了？
　　好在老丁又及时出现了，他这次没有修改表结构，而是和开发人员进行了半小时的交谈，然后居然对SQL进行重写，改改改！然后 SQL就变得飞快了。小王傻眼了，不是说尽量不着急先动手改SQL吗？怎么老丁一看到这SQL就改改改。悲催啊，该怎么做才是对的！让小王悲催的还不止这个，老丁的新SQL看上去并不是很复杂，可是小王居然看不懂老丁为什么能这么改写。
　　没错，看不懂！他看不懂老丁写什么，也完全不理解新旧SQL的等价性。
　　可怜的人！老师，我觉得不是"一入IT深似海，从此菜鸟泪成河。"而是"一入SQL深似海，从此优化泪成河。"
　　结论：SQL优化不是一件容易的事，明明优化后变快了，结果不一会儿又慢了。有时不改写可以解决问题，有时又必须要改写才能解决问题。让人难以适应。
　　析SQL之悲催故事
　　你故事听完了，啥感想，就是觉得小王好惨，优化很难吗？
　　嗯，差不多吧。
　　好吧，让我来解读一下这些故事吧。故事1里小王能定位到具体SQL，并且能根据SQL执行计划进行SQL优化，这至少说明了小王还是掌握了一定的SQL优化基础技能的，否则估计执行计划是什么都没有听过。不过接下来的故事2和故事3说明他是失败的。为啥呢？那是因为他经验太少，同时也缺乏由经验转换而成的做事方法论。
　　我是怎么下的这个结论呢？你注意到没，小王他接到电话后就开始动手优化了。他难道不应该多问一句这问题是一直以来就存在呢，还是今天忽然出现的。
　　老师，问这有啥用呢？
　　如果是第一次出现，你可能就会关注一下是否昨晚系统做了啥动作，比如昨晚打了一个补丁，这补丁引发这次故障的可能性就非常大，于是目标就很清晰了。在实在无法解决的情况下，回退补丁也是一个思路。而如果是经常有这故障，那应该有其他同事处理应对过，获取他们之前的分析成果，或者收集之前的日志和现在进行比对，这些难道对小王没帮助吗？
　　老师，事实上是不是因为晚上打补丁导致的？
　　你可以认为是，也可以认为不是。我说明一下，这几个故事没有真相，只是解读一下。真相不重要，你猜测的过程就是你进步的过程。另外这里小王是加了一个索引，你觉得这个动作是对的还是错的？
　　老师，我觉得应该是错的，因为在第3个故事里，他加索引后，系统虽然前期变快，但是后来又慢了。我觉得这个加的索引没有用，或者至少是没有解决全部问题。不过我就是奇怪为啥时快时慢？
　　这没啥奇怪的，我们还是进行假设。你不觉得可能有这么一种情况，此时整个系统都非常地慢，根本不只是这个菜单慢。求助者没有提出其他模块慢或许只是因为他平时仅用这个菜单，那你想想，如果整个平台都瘫痪了，局部能快起来吗？
　　哦，这我怎么一点都没想到啊！
　　嗯，我只是说可能性。那为什么整个数据库都慢？可能性更多了，比如数据库主机上某些应用程序耗尽了主机的CPU、内存等资源，数据库运行在这台主机上，覆巢之下安有完卵？ 接下来解释为啥忽快忽慢问题，正常啊，如果这些害人的应用程序有时运行，有时结束，结束时数据库不就正常了？
　　原来如此啊，第3个故事里的小王崩溃得好冤啊，如果知道事实的真相，他把数据库主机的程序停了或者优化了或者移到别的地方去，就解决问题了。
　　你的这个解决方案非常棒，不过别忘了我这里不说真相，一切都是可能性解读。当然这些可能性猜测是基于经验和推理的，也不是完全没依据的。另外，故事2里描述菜单曾经出错了几分钟，你注意到并思考过为什么了吗？
　　有的，不过这是为啥呢？
　　你没注意到建索引也是几分钟时间吗？几乎可以肯定地说，是这个建索引动作导致的故障。因为建索引会锁全表，这时候更新数据肯定会失败。小王犯了一个大错，在业务高峰期做DDL操作，严重地影响了生产，问题解决者成了麻烦制造者。这故事2倒是不需要推测的，真相一定如此。
　　哇，这么严重的错误原来是小王一手造成的，我还真没想到。
　　嗯，再说故事4吧，小王动手改改改，然后效果差差差，这里我们可以解读到什么呢？那就是解决问题要有目的性，不能没找到真正原因盲目动手。你看他觉得SQL写得不好，就改。实际上应该观察慢在什么地方，比如可以通过执行计划看出最大的开销在某全表扫描上，而该全表扫描完全可以通过索引减少访问路径，这时加索引就可以解决问题，改写SQL不可能解决问题的。
　　哦，确实如此。
　　接下来，在故事5里，老丁果然只是增加了索引后就解决了性能问题。优化SQL不一定非要改写才可以优化，有时根据数据库的体系逻辑结构不改写SQL也可完成优化。改写SQL的代价也更高，因为现实中如果你要改SQL肯定需要经过测试、打补丁、上线等多个过程，不可能直接就在生产中修改。
　　最后看故事6，小王学习老丁只调整参数进行SQL优化。接下来剧情反转了，小王学老丁不改，效果差差差。而老丁则动手改改改，效果又是杠杠的。小王欲哭无泪，不知自己该如何做了。其实这里小王生搬硬套了，他没有找到本质原因，比如此时可能是由于冗长的写法导致表访问了多次，而老王改写SQL将表访问次数大幅度降低下来。这时不改写是无法优化的。又或者是老丁根据业务需求，砍掉了某些多余的逻辑，这就更需要改写SQL了。
　　哦，老师您总结得很到位啊！
　　由于不改写通常来说比改写高效，而不改写的优化一般都和数据库的体系逻辑架构有关。因此我们需要认真学习这部分基础知识，这也就是老师的SQL优化课程中为什么会涉及这部分知识的原因。不过能不改写优化固然好，有时等价改写也是必需的，而且改写其实分成两个部分：一个是等价改写；一个是根据业务改写。比如小王看某SQL写得很不顺眼，然后动手改改改，这显然是等价改写。而老丁和开发人员交谈了半个多小时，改造后的SQL连小王都看不明白，这就很可能是根据业务改写的。
　　明白了，原来如此。
　　业务改写是优化的最高境界，老丁通过和开发人员交流后发掘出真正的需求，然后写出来的代码表面上看和旧代码逻辑完全不等价，实际却等价。
　　哦，老师您能否解释一下什么叫真正需求？
　　好吧，还是讲生动点的例子吧。从前我曾经讲过一个《小余买鱼》的故事。小余妈妈一个劲地让小余买鱼招待客人，条件不允许的时候还坚持如此。后来小余让妈妈用冰箱里的牛肉来代替鱼，妈妈也猛然醒悟了，她忘记了需求的本质是做美味给大家分享。站在做美味这角度上看，去老远的地方买鱼和拿冰箱里的牛肉，又有什么区别呢？
　　我明白了，没有提炼到这层需求的人，真的很难理解吃牛肉和吃水煮鱼其实是一样的，代码改写前后表面上有这么大差距，也难怪小王会大惑不解。
　　是的，这里顺便再说一点，小王看不懂老丁写的SQL，也可能是因为老丁用了某些可能小王没见过的SQL语法来改写，我们这里称之为高级SQL。比如WITH子句、树形递归、分析函数，等等。
　　哦，好想见识一下。
　　结论：其实这一节想说的就是，做事要有方法论，要先整体后局部，解决问题要注重效率，先尽量考虑不改写的优化，再考虑改写的优化。而不改写的优化靠的是体系结构知识的沉淀，而改写则要考虑逻辑等价改写和业务改写两大思路，其中业务改写是SQL优化的最高境界。另外还是要有一定的知识沉淀，高级SQL的语法也要掌握，其在很多场合下能帮上我们大忙。
　　推规范流程之必要
　　其实小王的系列故事还暴露了他身上一个非常重要的缺陷，那就是做事缺乏流程、缺乏规范。先不说解决问题的方法论，小王在系统中建了索引后导致系统出现问题，就是犯了一个不规范操作的低级错误。这应该在DBA的工作流程中是明确禁止操作的。当然小王有权限做这件事也是值得深究的，这种权限是不是要管控得更严格一些？这里涉及了作业流程规范。
　　接下来小王手忙脚乱地进行优化，是不是都很有序？他要花一小时时间才定位到某处需要建立索引，如果建索引有依据的规范并且能快速被体检报告诊断出来，他需要花一小时吗？这里涉及了数据库的设计规范。
　　故事中还涉及SQL改写优化的过程，如果性能低下的SQL在运行之前能被事先捞取出来，则很多故障就能避免。这里涉及SQL写法的规范。
　　规范不仅重要，我们更要主动去履行。如果我们能一键发现权限不当、数据库设计不良、SQL写法糟糕的问题，那规范就容易遵守，而不是停留在嘴上。不过放心，我们的数据库整体诊断工具，涵盖了这里大部分的规范检查。
　　结论：不成规矩，无以成方圆，如果能制定一定的规范并进行有效的检查，系统的性能问题必然会大幅减少。这里有一个好消息，就是这些要点大多都涵盖进笔者的一键获取数据库整体信息的脚本中了。

.　　本书适合于IT开发者、DBA、应用运维人员、IT爱好者、计算机专业学生，强烈推荐！
　　郭一军(guoyjoe)
　　尖峰在线教育创始人，浙江象行数据技术有限公司CEO
　　我对梁敬彬先生的第一感觉是勤奋。作为一双儿女的父亲，在业余时间还能独立完成两本著作，这本身就需要付出巨大的劳动。
　　我对梁先生的第二感觉是有为。集软件技术专家、培训讲师、围棋业余5段于一身，这充分体现了他的才智。
　　我对梁先生的第三感觉是亲和。我们从他的著作、他发表的文章，以及他的演讲都能体会到，"循循善诱、诲人不倦"这8个字。
　　这本《收获，不止SQL优化》，你从章节编排设计就能感受到梁先生的用心，书中的主题也正是数据库开发从业人员在工作学习中必然会遇到的。数据库开发博大精深，这本作者从他十多年的成功经验总结归纳出的指南，指引我们向正确的方向前进，少走弯路，健康成长。
　　卢涛
　　ITPUB Oracle开发版资深版主
　　系统分析师
　　早和梁敬彬先生认识是由于我们长期同在福建省内耕作Oracle并且一起经常被叫作"老师"。熟来熟往，因此了解敬彬演绎技术的风格是这样的：从读者的角度出发，在类似小品的故事情节中生活化地展示原先看似复杂的技术。这种风格太好了，尤其是用在深入演绎SQL优化这一项他的专长之上。读过书稿之后，我不禁拍案叫绝。像这样去传授SQL知识，去展现最佳实践，能让"开卷有益"这四个字实至名归。
　　长久以来中国东南地区Oracle技术交流讨论的气氛都不够浓郁。为了改变本地Oracle社区的现状，最近非常有幸我能和他一起作为SouthEast China Oracle Users Group（SECOUG）的发起人协力去建设我们自己的本地Oracle社区。在大量的现场技术培训和技术支持中，我们发现，中国东南地区其实不乏Oracle技术热爱者，只是缺乏像用户组这样的分享平台和分享平台上的有益读物。尤其是涉及比较复杂的SQL优化项目时，我们的Oracle技术热爱者们需要有人去引领和交流。敬彬的这本《收获，不止SQL优化》会成为这方面杰出的技术交流媒介，更能帮助SQL优化工作者们在个人技术生涯中因为阅读此书而有收获进而变得更为成熟。这本书也会成为SECOUG社区分享的重要读物。
　　唐波
　　中国科学院Oracle EBS最佳技术顾问，福建省知名Oracle WDP讲师
　　中国东南Oracle用户组SECOUG联合发起人，"DBA+社群"联合发起人
　　敬彬兄再次出书，依然是脑图逻辑为先，用语通俗易懂，细节深入浅出。我仔细拜读了第1、2、17章，敬彬兄不仅将SQL优化需要使用的工具做了全面详实的介绍，更结合他在不同行业的实际案例，用诙谐笔法娓娓道来。强烈推荐给还在优化之路上奋斗的DBA、开发人员们，你定会如书名所言，《收获，不止SQL优化》！
　　杨志洪
　　"DBA+社群"发起人，新炬网络首席布道师，Oracle ACE，《Oracle核心技术》译者
　　与吾兄敬彬相识九载，于剑破冰山始于交心，著述之道甚谨，曾有幸聆听吾兄传道，深入浅出，高屋建瓴，旁征博引，家事国事天下事信手拈来，堂上气氛甚悦，无他"乐"。
　　乐乃人与生俱来之追求，倘若没有乐，也就丧失了努力的动力。
　　当然入门之际，首先会"愁"和"懵"。Oracle发展至今已40年，历经若干版本，并得以在大数据、云计算和去IOE的大势之下屹立不倒，得益于Oracle自身体系架构的严谨和不断完善，洋洋洒洒数十万页官方文档，即使一辈子也未必能穷就。敬彬之特长就在于化繁就简，由道入术，轻松愉悦中掌握SQL优化之技能，一个字"爽"。
　　弟不才，混迹于各大IT论坛，尝闻"术业有专攻"，予则一塌糊涂，得蒙写荐言，不慎惶恐。
　　王保强
　　某移动公司首席架构师，IT畅销书作者
　　敬彬的新作《收获，不止SQL优化》的目标非常聚焦。和某些同类书籍哒哒哒地扫射不同，它是以精准狙击的方式直接锁定数据库领域的难点和痛点，即"SQL优化"这个话题，宁小不贪大，求透不求全。
　　难能可贵的是，本书并没有多少高深莫测的理论，内容非常接地气，属于即学即用、一用见效的类型。那是因为，书里所有智慧都是从作者和他的同事们实践中萃取并在实践中得到反复验证的，所有代码都是两位作者一行一行亲自敲出来的，大多数的案例、故事源自真实的工作场景，可以找到事件的原型。
　　这本书在易学、易用方面，下了很多苦功。但凡有点SQL基础的人，看这本书一定不费劲。仿佛有一位优秀的导游，拿着一张详尽的地图，手把手牵着你一路逛过去，你压根不用担心自己迷路。在此预祝读者朋友读书读人，见仁见智，受益多多！
　　王法松
　　企友咨询CEO，知识管理专家，知名课程开发师
　　和敬彬的第一次相识，是源于2015年福建IT培训联盟的成立，福富大学校长陈明先生第一个就向我推荐了敬彬。敬彬给我的第一印象是非常谦虚，他一直强调自己并不是什么大师，只是比别人多了一些工作总结，把总结编辑成书籍而已，在我翻看他的第一本数据库专著《收获，不止Oracle》时，便被他独到的写书风格所吸引，在业界能干会说的工程师难寻，能干会说还能写得一本好书的技术专家更是凤毛麟角，他无疑是后者。
　　敬彬让我欣赏的另一点是感恩、开放、共享的个性和理念，每当他有机会分享自己的成长经历时，总是用各种方式真诚流露出感恩之情，如今他正以自己的努力和付出回报这个社会。福建IT培训联盟成立之初，他开放分享的理念感染了一群怀有技术梦想的年轻人投身到联盟的公益服务。他专精数据库技术，点滴成河，汇聚成海，孜孜不倦，匠心可见，《收获，不止SQL优化》一书是福建IT培训联盟的优秀代表和骄傲。
　　黄美龙
　　福建IT培训联盟创始人，福州市软件行业协会副秘书长

.　　我要感谢我们项目组团队的成员，没有黄锏、荣志等公司杰出的技术专家和我并肩作战，我也没有精力写完这本书。我要感谢姚建艺、郑清泉、郑超群等，他们为我们团队的工作提供了最有力的帮助。要特别感谢我们的杨总，她一如既往的支持、她热情洋溢的《序》让我感动不已！
　　我要感谢我弟梁敬弘在本书内容上倾注精力。感谢林舒楠、张凤为本书在视觉设计上提供的帮助。感谢谢恒忠在线上拓展方面提供的帮助。谢谢你们的参与！
　　此外，我要感谢苏旭晖、卢涛、丁俊等这几位业内知名的数据库专家对本书的审核校验，感谢博文视点在出版方面的专业性指导意见。感谢大家的帮助！
　　最后，我要感谢我亲爱的家人，谢谢你们的支持！
　　梁敬彬
　　2017年4月