1.索引组织表:

    在InnoDB存储引擎中,表都是依照主键顺序组织存放的。这样的存储方式的表称为索引组织表,在innodb存储引擎表中,每张表都有主键。假设创建的时候没有显式定义主键,则InnoDB会依照例如以下方式选择或者创建主键:
 1). 首先推断表中是否有非空的唯一索引,假设有。则该列就为主键。
 2).   假设不符合上述条件,则innodb会自己主动创建一个6字节大小的指针 
假设表中有多个非空唯一索引时,InnoDB将选择建表时第一个定义的非空唯一索引为主键,通过_rowid能够显示表的主键,可是仅仅能查看单个列作为主键的情况,对于多列组成的主键则不能够。

 
2.InnoDB逻辑存储结构
   全部数据都会被逻辑的存放在一个空间中。称为表空间,表空间由段(segment)、区(extent)、页(page)组成。页有时候也成为块(block)。
     表空间:
            全部数据都存放在表空间。默认情况下有个共享表空间ibdata1,假设启用了參数innodb_file_per_table。则每张表的数据能够单独放到一个表空间中(默觉得96kb)。可是仅仅存放一定的数据(数据、索引和插入缓冲bitmap页),其它的数据还是存放在共享表空间中,因此在启用这个參数后。共享表空间的大小还是会不断增大。并且innodb存储引擎不会在事务运行rollback时去收缩这个表空间,会推断这些信息是否还须要,不须要则标为可用空间供下次使用。
    段(segment):表空间由各个段组成,常见的段有数据段(B+树的叶子节点)、索引段(B+树的非叶子节点)、回滚段等。
                               存储引擎中对段的管理是自身完毕的。

    区(extent): 区是由连续页组成的空间,不论什么情况下每一个区的大小都为1MB。为了保证区中页的连续性,innodb一次从磁盘申请4-5个区,默认情况下innodb页的大小为16kb,即一个区有一共同拥有64个连续的页。从innodb1.0.x版本号開始引入压缩页,即每一个页的大小能够通过參数KEY_BLOCK_SIZE设置为2K、4k、8k。

innodb1.2.x版本号開始新增參数innodb_page_size能够将默认页的大小设置为4k、8k,可是页中的数据库不是压缩。

 
            当中包括一个问题就是用户启用了innodb_file_per_table參数后。创建的表默认大小是96kb,可是区中是64个连续的页,创建的表的大小应该至少是1MB才对,由于在每一个段開始时。先用32个页大小的碎片页来存放数据,使用完之后才申请64个连续页,为了节省磁盘容量的开销。
 
 页(page): 页是innodb磁盘管理的最小单位。默认每一个页的大小为16KB。常见的页有:数据页、undo页、系统页、事务数据页、插入缓冲位图页等。
   
行:每一个页存放的行记录最多同意存放16kb/2-200行记录,
3.innodb行记录格式:
  
      innodb存储引擎中的记录是以行的形式存储的。这意味着页中保存着一行行的数据,在innodb1.0.x之前,提供了compact和redundant两种格式存放行记录数据,
 
 3.1. compact行记录格式:
 
        mysql5.0以后引入,为了高效的存储数据,一个页中存放的行数据越多,性能越高,其存储方式为:
 

首部是一个非NULL变长字段长度列表,长度最大不超过2字节,第二部分是null标志位。指示该行数据是否含有null值,有就用1表示,记录头信息固定占用5字节(40位),最后就是实际存储每列的数据。特别注意,null不占用该部分不论什么空间,除了占用null标志位。还有就是每行数据除了用户自己定义的以外,还包括隐藏列。事务id列和回滚指针列。各自是6字节和7字节的大小 ,假设没有主见。每行还会添加一个6字节的rowid列。

3.2. redundant行记录格式:
      是mysql5.0版本号之前的行记录存储方式。之后仍然支持这个格式是为了兼容之前版本号的页格式,其存储方式例如以下:



首部是一个字段长度偏移列表,也是依照列的顺序逆序放置的,第二部分记录头信息占用6字节,最后就是实际存储的每列的数据。


3.3. 行溢出树据
        innodb存储引擎能够将一条记录的某些数据存储在真正的数据页面之外,一般将blob、lob这类的大对象列类型的存储会把数据存放在数据页面之外,可是,这样的理解有点偏差。能够将varchar列数据类型存放为行溢出数据,mysql数据库的varchar类型能够存放65535字节,可是实际上并不会存放65535字节。当中还有别的开销。实际仅仅能存放65532字节。并且官方定义的65535长度是指全部varchar列的长度总和,假设列的长度总和超过这个长度。依旧无法创建。
       Innodb存储引擎的数据都是存放在页类型的B-tree node中,可是当发生行溢出时,数据存放在页类型为uncompress BLOB页中。实际上仅仅有768字节的前缀数据保存在数据页中,之后是偏移量。指向行溢出页(uncompress BLOB page),那么就引出多长的varchar是保存在单个数据页中,从多长開始保存在BLOIB页呢?思考:innodb是索引组织的。也就是B+ tree的结构。这样每一个页中至少有两条行记录(否则就失去了B+
tree的意义,变成链表了),因此假设一个页仅仅能存放一条记录,那么innodb存储引擎会自己主动将行数据存放在溢出页中。
3.4  compressed和dynamic格式
      inndob1.0.x開始引入新的文件格式,曾经支持的compact和redundant格式称为antelope文件格式,新的文件格式称为barracuda文件格式,barracuda文件格式拥有两种新的行记录格式:compressed和dynamic格式。
 
  新的行记录格式对于存放在BLOB中的数据採用了全然的行溢出方式,在数据页中仅仅存放20字节的指针,实际的数据都存放在off page中(不同于compact和redundant格式会存放768个前缀字节),
      compressed另一个功能 就是存放在当中的数据会以zlib的算法进行压缩,因此对于BLOB、text这类大长度数据可以进行很有效的存储。

3.5 char的行结构存储
      存储固定长度的字符类型,mysql4.1版本号開始char(N)中的N指的是字符的长度,而不是之前的字节的长度,因此在不同的字符集下。char类型相应的列内部存储的可能不是定长的数据,因此对于多字节字符编码的char类型的存储,innodb在内部将其视为变长字符类型,


4.innodb数据页结构
 
由下面7个部分组成:
      file header(文件头):定长 38字节
      page header(页头):56字节,用来记录数据页的状态信息,0x45BF表示数据页。
      infimum和supermum records:
               在每一个数据页中有两个虚拟的行记录,用来限定记录的边界。infimum记录是比该页中不论什么主键都要小的值。supermum records是比不论什么可能大的值还要大的值,这两个值在页创建时被建立,而且不论什么情况下不会被删除,在两种不同的行记录格式下所占字节数不同。
      user records(用户记录,即行记录)和free space(空暇空间): 
              free
space是链表数组结构,在一条记录被删除后。该空间就会被增加到空暇链表中     
      page directory(页文件夹):
                存放了页的相对位置,这些记录指针有时候也称为槽或者文件夹槽,在Innodb中。并非每条记录拥有一个槽,innodb的槽是一个稀疏文件夹,即一个槽可能包括多个记录。当记录被删除或者被插入时。须要对槽进行分裂或平衡的维护操作,
      file trailer(文件结尾信息):定长 8字节    
              为了检測页是否已经完整写入了磁盘

InnoDB存储引擎表的逻辑存储结构的更多相关文章

  1. InnoDB的表类型,逻辑存储结构,物理存储结构

    表类型 对比Oracle支持的各种表类型,InnoDB存储引擎表更像是Oracle中的索引组织表(index organized table).在InnoDB存储引擎表中,每张表都有个主键,如果在创建 ...

  2. InnoDB存储引擎表的主键

    在InnoDB存储引擎中,表是按照主键顺序组织存放的.在InnoDB存储引擎表中,每张表都有主键(primary key),如果在创建表时没有显式地定义主键,则InnoDB存储引擎会按如下方式选择或创 ...

  3. mysql数据库 myisam数据存储引擎 表由于索引和数据导致的表损坏 的修复 和检查

    一.mysqlcheck 进行表的检查和修复 1.检查mysqlisam存储引擎表的状态 #mysqlcheck -uuser -ppassword database  table  -c  #检查单 ...

  4. {MySQL存储引擎介绍}一 存储引擎解释 二 MySQL存储引擎分类 三 不同存储引擎的使用

    MySQL存储引擎介绍 MySQL之存储引擎 本节目录 一 存储引擎解释 二 MySQL存储引擎分类 三 不同存储引擎的使用 一 存储引擎解释 首先确定一点,存储引擎的概念是MySQL里面才有的,不是 ...

  5. INNODB存储引擎表空间

    这片文章主要是对innodb表空间的一些说明: innodb中表空间可以分为以下几种: 系统表空间 独立表空间 undo表空间 临时表空间(temporary tablespace) 通用表空间(ge ...

  6. MySQL的nnodb引擎表数据分区存储

    Symlinks are fully supported only for MyISAM tables. 对应Innodb引擎数据文件放到其他目录 mysql> SHOW VARIABLES L ...

  7. InnoDB存储引擎介绍-(5) Innodb逻辑存储结构

    如果创建表时没有显示的定义主键,mysql会按如下方式创建主键: 首先判断表中是否有非空的唯一索引,如果有,则该列为主键. 如果不符合上述条件,存储引擎会自动创建一个6字节大小的指针. 当表中有多个非 ...

  8. InnoDB 逻辑存储结构

    本文同时发表在https://github.com/zhangyachen/zhangyachen.github.io/issues/80 如果创建表时没有显示的定义主键,mysql会按如下方式创建主 ...

  9. MYSQL Innodb逻辑存储结构

    转载于网络 这几天在读<MySQL技术内幕 InnoDB存储引擎>,对 Innodb逻辑存储结构有了些了解,顺便也记录一下: 从InnoDB存储引擎的逻辑存储结构看,所有数据都被逻辑地存放 ...

随机推荐

  1. Visual Studio 2012连接TFS2010登录不了

    一直用VS2012+TFS2010开发项目, 最近几天忽然很不正常, 在VS中会频繁要求输入TFS的账号密码, 经常要输入很多遍才可以正常连接签入签出. 这几天更甚, 基本上直接连接不了了. 网上找到 ...

  2. Windows之权限的继承性 累加性 优先性 交叉性及四项基本原则

    Windows NT以后的文件,及文件夹共享设置有以下特性:继承性.累加性.优先性.交叉性.     继承性是说下级的目录在没有经过重新设置之前,是拥有上一级目录权限设置的.这里还有一种情况要说明一下 ...

  3. DRP经验总结

    思想 指导 从开始看DRP项目到完成已经有三个月左右的时间了,这是一个足够长的视频,当看第一集的时候就再想,啥时候看完呢? 其间,也断断续续,有时看的效率高有时相反,有时几天看不了几集,好在总算看完了 ...

  4. DHCP安装配置详解

    DHCP基于客户/服务器模式.当DHCP客户端启动时,它会自动与DHCP服务器通信,由DHCP服务器为DHCP客户端提供自动分配IP地址的服务. 当然高级的DHCP,不光只是分配地址这么简单,今天我们 ...

  5. LXD 2.0 系列(一):LXD 入门

    LXD是提供了RESTAPI的LXC 容器管理器,主要是管理linux容器的第三方管理器.也许现在您还没有听说过,下面我们就来入门——介绍一下LXD 什么是 LXD ? 简单地说,LXD 就是一个提供 ...

  6. Cognos TM1_10.1.1服务端安装

    出于对bi行业的强大热爱,出于对cognos tm1的强大兴趣,于是就想研究一下Cognos TM1(table manager one),今天就分享一下自己微不足道研究成果,真可谓是tm1的九牛一毛 ...

  7. Cognos权限认证CJP方式之用户密码加密

    在项目开发过程中,用户往往对系统的安全都有明确的要求,下面针对cognos门户认证用户密码如何加密来提供一个简单的wf 1Cognos权限认证方式:CJP 2Cognos用户数据库类型:Oracle ...

  8. 初始小R-安装启动与测试

    非常感谢<深入浅出数据分析>这本书让我有幸认识了R,多多少少的弥补了我心里对R语言.R分析.R工具的模糊认知,下面我们就来体验一下R语言的魅力吧!GO! 一:下载R R官方地址:http: ...

  9. 【cocos2d-x 3.7 飞机大战】 决战南海I (七) 控制器的实现

    控制器中的功能并不多,主要是以下这些 //对玩家分数的操作 CC_SYNTHESIZE_READONLY(SaveData *, m_saveData, SaveData); void update( ...

  10. Spring MVC配置CORS(解决跨域请求)

    1. CORS 简介 同源策略(same origin policy)是浏览器安全的基石.在同源策略的限制下,非同源的网站之间不能发送 ajax 请求的. 为了解决这个问题,w3c 提出了跨源资源共享 ...