Oracle行链接(Row chaining) 与行迁移(Row Migration)

清疚 2021-08-29 15:23 248阅读 0赞

## ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70][] ##

## 一、char与varchar2的区别 ##

### 1、char的长度是固定的，而varchar2的长度是可以变化的。 ###

比如，存储字符串“101”，对于char(10)，表示你存储的字符将占10个字节（包括7个空字符），在数据库中它是以空格占位的，而同样的varchar2(10)则只占用3个字节的长度，10只是最大值，当你存储的字符小于10时，按实际长度存储。

### 2、char的效率比varchar2的效率稍高。 ###

### 3、何时用char，何时用varchar2? ###

char和varchar2是一对矛盾的统一体，两者是互补的关系，varchar2比char节省空间，在效率上比char会稍微差一点，既想获取效率，就必须牺牲一点空间，这就是我们在数据库设计上常说的“以空间换效率”。

varchar2虽然比char节省空间，但是假如一个varchar2列经常被修改，而且每次被修改的数据的长度不同，这会引起“行迁移”现象，而这造成多余的I/O，是数据库设计中要尽力避免的，这种情况下用char代替varchar2会更好一些。char中还会自动补齐空格，因为你insert到一个char字段自动补充了空格的,但是select 后空格没有删除，因此**char类型查询的时候一定要记得使用trim**，这是写本文章的原因。

如果开发人员细化使用rpad()技巧将绑定变量转换为某种能与char字段相比较的类型（当然，与截断trim数据库列相比，填充绑定变量的做法更好一些，因为对列应用函数trim很容易导致无法使用该列上现有的索引），可能必须考虑到经过一段时间后列长度的变化。如果字段的大小有变化，应用就会受到影响，因为它必须修改字段宽度。

正是因为以上原因，定宽的存储空间可能导致表和相关索引比平常大出许多，还伴随着绑定变量问题，所以无论什么场合都要避免使用char类型。

## 二、Oracle行链接(Row chaining) 与行迁移(Row Migration) ##

当一行的数据过长而不能插入一个单个数据块中时，可能发生两种事情：行链接(row chaining)或行迁移(row migration)。

### 1、行链接 ###

当第一次插入行时，由于行太长而不能容纳在一个数据块中时，就会发生行链接。在这种情况下，Oracle会使用与该块链接的一块或多块数据块来容纳改行的数据。行链接经常在插入比较大的数据时才会发生，如包含long,long row,lob等类型的数据，这种情况下行链接是不可避免的。

### 2、行迁移 ###

当修改不是行链接的行时，当修改后的长度大于修改前的行长度，并且该数据块中的空闲空间已经比较小而不能完全容纳该行的数据时，就会发生行迁移。在这种情况下，Oracle会将整行的数据迁移到一个新的数据块上，而将该行原先的空间只放一个指针，指向改行的新位置，而且该行原先空间的剩余空间不再被数据块使用，这些剩余的空间我们将其称之为空洞，这就是产生表碎片的主要原因，表碎片基本上也是不可避免的，但是我们可以将其降到一个我们可以接受的程度。注意，即使发生了行迁移，发生了行迁移的行的rowid还是不会变化，这也是行迁移会引起数据库I/O性能降低的原因。其实行迁移是行链接的一种特殊形式，但是它的起因和行为和行链接有很大不同，所以一般把它从行链接中独立出来，单独进行处理。

### 3、行链接和行迁移引起数据库性能下降的原因 ###

主要是由于引起多余的I/O造成的，当通过索引访问已有行迁移现象的行时，数据库必须扫描一个以上的数据库才能检索到该行的数据，导致insert或update时性能较差，因为需要执行额外的处理。利用索引查询已经链接或迁移的行时，select语句的性能比较差，因为要执行额外的I/O。

### 4、预防方法 ###

*  数据块的pctfree调大；
 *  针对表空间扩大数据块大小；

![20200608150301424.jpg][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70]: /images/20210813/98492cce36424c298339c578787879e0.png
[20200608150301424.jpg]: /images/20210813/bbbbd7af9c8e4631be5b2ff311a381cf.png