关于SQL优化
说句大废话，那就是“合理的平衡各种资源的使用,内存,cpu,io 等等”。这也是很有道理的，但是实际就不好做了，如何平衡呢？
具体点的么，通过比较，应该是响应时间做为主要的评判因素了。但是可能由于一些不确定的因素，可能会出现：这次跑的快，不等于下次也跑的快了。
那就要根据表的数据量的变化，确定一个比较合理的执行计划了，主要还是要降低逻辑读为调优的目标，其实物理读意义不大，一个sql语句第一次执行物理读肯定是很大的，到了第2次物理读也许就很小了。
某高人说：
在数据库整体上来讲，是要降低 物理读
而对于单条 sql 来讲，是以逻辑读的降低为标准的
道理很简单，对于单条sql来说，如果反复运行，物理读决定于 data buffer 的大小 ，第一次运行 和 第二次运行也是不一样的。
但比较稳定的是 逻辑读。 如果以物理读为标准，那难道物理读为0的sql就是好sql 了？如果sql的逻辑读都良好，那数据库整体的物理读降下来也是很自然的事情
高人又说：
临时段是不会生产redo 的
buffer gets 就可以理解为 对 buffer cache 中 buffer 的访问 buffer*次 ，也可以看做访问的 buffer数量，当然可能存在着一个buffer被访问多次的情况
至于 buffer gets，如果访问的块不在内存中自然就产生物理读，可物理读并不影响buffer gets ,因为对数据的访问最终是在内存中完成的，虽然额外地有物理读。
db block gets 仅仅表示 类似dml这类操作去访问数据块，dml 操作数据最终也是在访问buffer的过程中完成的啊，而 consistent gets 表示类似 select这样的查询去访问buffer。 更严格来说，是叫 current mode and query mode .这是oracle的读一致性的特点决定的
相关文档：
在PL/SQL程序设计中，有三种定义记录类型的方法：一种是使用%ROWTYPE属性；另一种是在PL/SQL程序的声明部分显示定义记录类型；最后一种方法是将记录类型定义为数据库结构或对象类型。
我先简单的介绍一个下面要用到的表的结构（黑体标明的字段为主键）：
INDIVIDUALS表
INDIVIDUAL ID
FIRST NAME
MIDDLE_INITI ......
三、嵌套表的使用方法
1、将嵌套表定义为PL/SQL的程序构造块
TYPE type_name IS TABLE OF element_type[NOT NULL];
如下例所示：
DECLARE
-- Define a nested table of variable length strings.
TYPE card_table IS TABLE OF VARCHAR2(5 CHAR);
-- Declare and initialize a n ......
ORACLE 10G的集合API
集合API方法最早是在ORACLE 8I中引入的。集合API提供了简化访问集合的方法。在ORACLE 10G以前，这些方法确实简化了对集合的访问。但是，并不是非要求掌握这些方法不可。从ORACLE 9I的INDEX-BY表到ORACLE 10G的联合数组的转换，使它们成为必须掌握的方法。
下面是我从书上摘录下的一� ......
ORACLE SQL语句优化总结
1） 选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE的解析器按照从右到左的顺序处理from子句中的表名，from子句中写在最后的表(基础表 driving table)将被最先处理，在from子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, � ......
刚刚在inthirties老大的博客里看到这篇文章，写的不错，正好自己最近在学习PL/SQL，转过来学习学习。
==================================================================================
bulk collect是可以看做是一种批获取的方式，在我们的plsql的代码段里经常作为into的扩展来使用。对于select id into v from ... ......
