小的块：
小的块降低块竞争，因为每个块中的行较少.
小的块对于小的行有益.
小的块对于随意的访问较好.如果一个块不太可能在读入内存后被修改，那么块的大小越小使用buffer cache越有效率。当内存资源很珍贵时尤为重要，因为数据库的buffer cache是被限制大小的。
劣势：
小块的管理消费相对大.
因为行的大小你可能只在块中存储很小数目的行，这可能导致额外的I/O。
小块可能导致更多的索引块被读取

大的块
好处：
更少的管理消费和更多存储数据的空间.
大块对于有顺序的读取较好.  譬如说全表扫描
大块对很大的行较好
大块改进了索引读取的性能.大的块可以在一个块中容纳更多的索引条目,降低了大的索引级的数量.越少的index level意味着在遍历索引分支的时候越少的I/O。
劣势：
大块不适合在OLTP中用作索引块,因为它们增加了在索引叶块上的块竞争。
如果你是随意的访问小的行并有大的块，buffer cache就被浪费了。例如，8 KB的block size 和50 byte row size,你浪费了7,950

如：自动装箱，它可以直接把基本类型赋值给封装类型

Integer num = 10 ;

Double d = 2d ;

自动拆箱，它可以把封装类型赋值给基本类型

int num = new Integer(10);

double d = new Double(2d);

自动装箱与拆箱的功能事实上是编译器来帮您的忙，编译器在编译时期依您所编写的语法，决定是否进行装箱或拆箱动作。在自动装箱时对于值从-128到127之间的值，它们被装箱为Integer对象后，会存在内存中被重用，所以范例4.6中使用==进行比较时，i1 与 i2实际上参考至同一个对象。如果超过了从-128到127之间的值，被装箱后的Integer对象并不会被重用，即相当于每次装箱时都新建一个Integer对象，所以范例4.7使用==进行比较时，i1与i2参考的是不同的对象。所以不要过分依赖自动装箱与拆箱，您还是必须知道基本数据类型与对象的差异。

    public void testBoxingUnboxing() {

        int i = 10;

        Integer inta = i;

        inta++;

        inta += 1;

        int j = inta;

        assertTrue(j == inta);结果是：true//junit里面的方法

        assertTrue(j == new Integer(j)); 结果是：true

        assertTrue(10000 == new Integer(10000)); 结果是：true

    }

Integer i = 100.相当于编译器自动为您作以下的语法编译：

Integer i = new Integer(100).所以自动装箱与拆箱的功能是所谓的“编译器蜜糖”(Compiler Sugar)，虽然使用这个功能很方便，但在程序运行阶段您得了解Java的语义。例如下面的程序是可以通过编译的：

Integer i = null.int j = i.这样的语法在编译时期是合法的，但是在运行时期会有错误，因为这种写法相当于：

Integer i = null.int j = i.intValue().null表示i没有参考至任何的对象实体，它可以合法地指定给对象参考名称。由于实际上i并没有参考至任何的对象，所以也就不可能操作intValue()方法，这样上面的写法在运行时会出现NullPointerException错误。

自动装箱、拆箱的功能提供了方便性，但隐藏了一些细节，所以必须小心。再来看范例4.6，您认为结果是什么呢？

Ü. 范例4.6 AutoBoxDemo2.java

public class AutoBoxDemo2 {

public static void main(String[] args) {
Integer i1 = 100;

Integer i2 = 100;

if (i1 == i2)

System.out.println("i1 == i2");

else

System.out.println("i1 != i2").

}

}

从自动装箱与拆箱的机制来看，可能会觉得结果是显示i1 == i2，您是对的。那么范例4.7的这个程序，您觉得结果是什么？

Ü. 范例4.7 AutoBoxDemo3.java

public class AutoBoxDemo3 {

public static void main(String[] args) {

Integer i1 = 200;

Integer i2 = 200;

if (i1 == i2)

System.out.println("i1 == i2");

else

System.out.println("i1 != i2");

}

}

结果是显示i1 != i2，这有些令人惊讶，两个范例语法完全一样，只不过改个数值而已，结果却相反。

其实这与==运算符的比较有关，在第3章中介绍过==是用来比较两个基本数据类型的变量值是否相等，事实上==也用于判断两个对象引用名称是否参考至同一个对象。

在自动装箱时对于值从–128到127之间的值，它们被装箱为Integer对象后，会存在内存中被重用，所以范例4.6中使用==进行比较时，i1 与 i2实际上参考至同一个对象。如果超过了从–128到127之间的值，被装箱后的Integer对象并不会被重用，即相当于每次装箱时都新建一个Integer对象，所以范例4.7使用==进行比较时，i1与i2参考的是不同的对象。

所以不要过分依赖自动装箱与拆箱，您还是必须知道基本数据类型与对象的差异。范例4.7最好还是依正规的方式来写，而不是依赖编译器蜜糖(Compiler Sugar)。例如范例4.7必须改写为范例4.8才是正确的。

Ü. 范例4.8 AutoBoxDemo4.java

public class AutoBoxDemo4 {
public static void main(String[] args) {

Integer i1 = 200;

Integer i2 = 200;

if (i1.equals(i2))

System.out.println("i1 == i2");

else

System.out.println("i1 != i2");

}

}

结果这次是显示i1 == i2。使用这样的写法，相信也会比较放心一些，对于这些方便但隐藏细节的功能到底要不要用呢？基本上只有一个原则：如果您不确定就不要用。

.fnm的文件格式：   （Field的信息）
int:               Field的个数，最少为1，最少有一个Field("",false)，在初始化的时候写入(暂时不知道原因); 名称为空字符串，未索引，        未               向           量化。readVInt()读取
String: byte      String是 Field的名称  byte指示该Field 是否被索引，是否向量化 （值有：11，10，01）第一个1代表被索引，第二个代表被向量化
String: byte Field 同上     

.fdx的文件格式：主要是提供对.fdt中存储的document的随即读取
long :       第一个document在.fdt文件中的位置
long:        第二个document在.fdt文件中的位置

.fdt的文件格式：  .fdt文件存储了一系列document的信息
VInt:        该document中的isStored属性为true的域的个数
(VInt:)      如果该field的isStored属性为true则得到该field的fieldNumber，暂时不知道这个fieldNumber是怎么产生的，有什么用，初步估计是按照field创建的顺序产生的，每次再上一个field的fieldNumber基础上加1。
byte:        如果该field的isTokenized属性为true写入1否则写入false。
String:      该field的stringValue()值。
一个document结束，下面的数据将会开始一个新的document，每个新的document的开始点的文件位置都会在.fdx中有记载，便于随即访问