表的特性

所学的知识点，有的适用于这个应用场景，却不适合另外一个场景，要学会选择性地使用各种技术。

普通堆表的不足之处

表位于体系物理结构的数据文件部分，在体系逻辑结构中，一张表就是一个段，如果该表有索引，一个索引就是一个段。

Oracle中表的分类是多种多样的，除了普通表，还有全局临时表、外部表、分区表、索引组织表等具有其他特性的表。

普通表可以实现大部分功能，但是这里说的是功能，而不是性能。

各种类型的表都有优缺点，要善于取长补短，灵活利用。

表更新日志开销较大

该脚本利用v$statname和v$mystat两个动态性能视图来跟踪当前SESSION操作产生的日志量，首先执行该脚本，查看日志大小，随即执行更新语句，再执行该脚本查看返回的日志大小，两者相减，就是此次更新语句产生的日志大小。

删除语句产生了20 233 304-110 132=20 123 172的日志量。这个量的单位是字节数，因此大致产生了20MB的日志。

插入语句产生了26 358 732-20 233 304=6 125 428字节，也就是大约6MB的数据。

更新语句产生了33 335 524-26 358 732=6 976 792字节，大约7MB的数据。

对表的更新操作，无论是删除、插入还是修改，都会产生日志。

这些日志是用于数据库的备份和恢复的。如果仅从性能角度而不从安全性角度来考虑，更新表写日志就意味着数据库多做了额外的事情而影响了效率，虽说安全第一，不过在某些特定的场合，某些表的记录只是作为中间结果临时运算而根本无须永久保留，这些表无须写日志，那就既高效又安全了！——全局临时表

删除产生的redo最多！

删除产生的undo最多，而undo也是需要redo保护的，所以虽然本身产生的redo不多，但是由于删除时的undo量最大，用于保护undo的redo量也最大，所以加在一起，删除产生的redo也就可能最多了。

delete无法释放空间

delete是最耗性能的操作，产生的undo最多，而且因为undo需要redo来保护的缘故，delete产生的redo量也最大，所以不少性能问题都和delete操作有关。

记录数从55 709减少到0条，怎么逻辑读还是771个：

逻辑读从771减少到3了，代价也从170多减少到2了

delete 删除并不能释放空间，虽然delete将很多块的记录删除了，但是空块依然保留，Oracle在查询时依然会去查询这些空块。而truncate是一种释放高水平位的动作，这些空块被回收，空间也被释放了。

truncate不能替代delete，因为truncate是一种DDL操作而非DML操作，truncate后面是不能带条件的，即truncate table t where…是不允许的。但是如果表中这些where条件能形成有效的分区，Oracle是支持在分区表中做truncate分区的，命令大致为 alter table t truncate partition ＇分区名＇，如果where 条件就是分区条件，那等同于换个角度实现了 truncate table t where…的功能。这就是分区表最实用的功能之一了，高效地清理数据，释放空间

当大量delete 删除再大量insert插入时，Oracle会去这些delete的空块中首先完成插入（直接路径插入除外），所以频繁delete又频繁insert的应用，是不会出现空块过多的情况的

表记录太多检索较慢

一是在无须考虑备份，允许不产生日志时普通表操作依然会产生大量日志，无法节省开销；二是 delete 操作开销大且无法释放空间。

一张表就是一个段，需要遍历该段的所有块来完成对该表进行更新查询等操作，在这种情况下，表越大，更新查询操作就越慢！“

主要思路就是缩短访问路径来完成同样的更新查询操作。完成同样的需求，访问块的个数越少越好。

Oracle为了尽可能减少访问路径提供了两种主要技术，一种是索引技术，另一种则是分区技术。

select * from t where created>=xxx and created <=xxx；

首先说索引，这是Oracle中最重要也最实用的技术之一。

如果created>=xxx and created <=xxx返回的记录非常少，或者说和T表的总记录相比非常少，则在created列建索引能极大提升该语句的效率。创建了一个idx_t索引，在用该SQL语句查询时首先会访问idx_t这个新建出来的索引段，然后通过索引段和表段的映射关系，迅速从表中获取行列的信息并返回结果。

减少访问路径的第二种技术就是分区。把普通表T改造为分区表，以created这个时间列为分区字段，从2010年1月到2012年12月按月建36个分区。早先的T表就有一个T段，，从1个大段分解成了36个小段，分别存储了2010年1月到2012年12月的信息。

假如created>=xxx and created <=xxx这个时间跨度正好落在2012年11月，那Oracle的检索只要完成一个小段的遍历即可，假设这36个小段比较均匀，可大致将其理解为访问量只有原来的三十六分之一，大幅减少了访问路径，从而高效地提升了性能。——分区表具有高效清理数据的功能，减少访问路径的神奇本领。

索引回表读开销很大

TABLE ACCESS BY INDEX ROWID根据索引来检索记录，会有一个先从索引中找到记录，再根据索引列上的ROWID定位到表中从而返回索引列以外的其他列的动作，这就是TABLEACCESS BY INDEX ROWID

没有TABLE ACCESS BY INDEX ROWID了！因为语句由 select * from t where object_id<=10；改写为 select object_idfrom t where object_id<=10；了，不用从索引中回到表中获取索引列以外的其他列了。

逻辑读从4变为2，代价从2变为1。

避免回表从而使性能提升，少做事性能当然有提升。只是select * from t 和select object_id from t不等价——可以使用索引组织表实现

有序插入却难有序读出

在对普通表的操作中，我们无法保证在有序插入的前提下就能有序读出。

把行记录插入块中，然后删除了该行，接下来插入的行会去填补块中的空余部分，这就无法保证有序了。

块大小默认是8KB，特意用rpad（＇*＇,4000,＇*＇）,rpad（＇*＇,3000,＇*＇）来填充B、C字段，这样可以保证一个块中只插入一条数据。按t表A字段的序列顺序依次插入，然后希望查询可以依据A字段的顺序展现t表记录。

有序应该展现1,3,4，结果却是1,4,3，说明无序了。第2条记录被删除了，第4条记录去填充第2条记录所在的块，所以无序了。

在查询数据时，如果想有序地展现，就必须使用orderby，否则不能保证按顺序展现，而order by操作是开销很大的操作：

有排序的操作的统计信息模块有一个1 sorts（memory），表示发生了排序，执行计划中也有SORT ORDER BY关键字，不过最重要的是，没排序的操作代价为3，有排序的操作代价为4，性能上是有差异的，这在数量大的时候将会非常明显。

关于order by 避免排序的方法有两种思路。第一种思路是在order by 的排序列建索引。第二种方法就是，将普通表改造为有序散列聚簇表，这样可以保证顺序插入，order by 展现时无须再有排序动作。