表就是关于特定实体的数据集合，这也是关系型数据库模型的核心。
在InnoDB存储引擎表中，每张表都有个主键（Primary Key），如果在创建表时没有显式地定义主键，则InnoDB存储引擎会按如下方式选择或创建主键：
❑首先判断表中是否有非空的唯一索引（Unique NOT NULL），如果有，则该列即为主键。
❑如果不符合上述条件，InnoDB存储引擎自动创建一个6字节大小的指针。
当表中有多个非空唯一索引时，InnoDB存储引擎将选择建表时第一个定义的非空唯一索引为主键。这里需要非常注意的是，主键的选择根据的是定义索引的顺序，而不是建表时列的顺序
_rowid 可以显示表的主键
从InnoDB存储引擎的逻辑存储结构看，所有数据都被逻辑地存放在一个空间中，称之为表空间（tablespace）。
表空间又由段（segment）、区（extent）、页（page）组成。页在一些文档中有时也称为块（block）
如果启用了innodb_file_per_table的参数，需要注意的是每张表的表空间内存放的只是数据、索引和插入缓冲Bitmap页
其他类的数据，如回滚（undo）信息，插入缓冲索引页、系统事务信息，二次写缓冲（Double write buffer）等还是存放在原来的共享表空间内。
插入缓冲Bitmap 插入缓冲页？(什么区别呀)
共享表空间还包含有 undo信息，执行rollback后并不会收缩表空间，会自动判断这些undo信息是否还需要，如果不需要，则会将这些空间标记为可用空间，供下次undo使用。（每 10 秒的 full purge）
段 segment
表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等。
因为前面已经介绍过了InnoDB存储引擎表是索引组织的（index organized），因此数据即索引，索引即数据。
数据段即为B+树的叶子节点（Leaf node segment）
索引段即为B+树的非索引节点（Non-leaf node segment）
回滚段较为特殊，将会在后面的章节进行单独的介绍。数据行基于聚集索引键按顺序存储。
非聚集索引不影响数据行的顺序
索引组织表（Index Organizied Table）
- 索引组织表(index organized table, IOT)就是存储在一个索引结构中的表。存储在堆中的表是无组织的(也就是说，只要有可用的空间，数据可以放在任何地方)，IOT中的数据则按主键存储和排序。对你的应用来说，IOT表和一个“常规”表并无二致。
- 索引组织表的数据按主键排序手段被存储在B-树索引中，除了存储主键列值外还存储非键列的值。普通索引只存储索引列，而索引组织表则存储表的所有列的值。
- 索引组织表一般适应于静态表，且查询多以主键列。当表的大部分列当作主键列时，且表相对静态，比较适合创建索引组织表！（8i以上）
既然它属于表，那么它当然也有建立索引的需求。由于它的索引的结构，比如说由于索引叶节点的分裂，行所在块可能会发生改变，因而建立在IOT上的索引和一般的索引的最大区别是它存的是IOT的行的逻辑地址，也就是UROWID，oracle用这个逻辑rowid来猜这个行所在的块，如果猜到了，那么这个urowid是正确的，否则它从这个地址向下遍历来找这条记录。
IOT表的rowid是逻辑上的，因为IOT表中的行的位置是在不断变化的(例如插入新的行，有可能带来其它行的位置移动)
IOT有什么意义呢？使用堆组织表时，我们必须为表和表主键上的索引分别留出空间。而IOT不存在主键的空间开销，因为索引就是数据，数据就是索引，二者已经合二为一。但是，IOT带来的好处并不止于节约了磁盘空间的占用，更重要的是大幅度降低了I/O,减少了访问缓冲区缓存(尽管从缓冲区缓存获取数据比从硬盘读要快得多，但缓冲区缓存并不免费，而且也绝对不是廉价的。每个缓冲区缓存获取都需要缓冲区缓存的多个闩，而闩是串行化设备，会限制应用的扩展能力)
IOT适用的场合有：
1、完全由主键组成的表。这样的表如果采用堆组织表，则表本身完全是多余的开销，因为所有的数据全部同样也保存在索引里，此时，堆表是没用的。
2、代码查找表。如果你只会通过一个主键来访问一个表，这个表就非常适合实现为IOT.
3、如果你想保证数据存储在某个位置上，或者希望数据以某种特定的顺序物理存储，IOT就是一种合适的结构。
IOT提供如下的好处：
提高缓冲区缓存效率，因为给定查询在缓存中需要的块更少。
减少缓冲区缓存访问，这会改善可扩缩性。
获取数据的工作总量更少，因为获取数据更快。
每个查询完成的物理I/O更少，因为对于任何给定的查询，需要的块更少，而且对地址记录的一个物理 I/O 很可能可以获取所有地址（而不只是其中一个地址，但堆表实现就只是获取一个地址）
如果经常在一个主键或惟一键上使用BETWEEN 查询也是如此，因为相近的记录存在一起，查询时引入的逻辑IO和物理IO都会更少。
堆表 heap table
堆表（heap table）数据插入时时存储位置是随机的，主要是数据库内部块的空闲情况决定，获取数据是按照命中率计算，全表扫表时不见得先插入的数据先查到。
堆表（heap table） 就是一般的表，获取表中的数据是按命中率来得到的。没有明确的先后之分，在进行全表扫描的时候，并不是先插入的数据就先获取。数据的存放也是随机的，当然根据可用空闲的空间来决定。
区 extent
区是由连续页组成的空间，在任何情况下每个区的大小都为1MB。为了保证区中页的连续性，InnoDB存储引擎一次从磁盘申请4～5个区。在默认情况下，InnoDB存储引擎页的大小为16KB，即一个区中一共有64个连续的页。
mysql> INSERT INTO t SELECT NULL,REPEAT('a',7000);
新创建表的默认大小是 96KB
在用户启用了参数innodb_file_per_talbe后，创建的表默认大小是96KB。区中是64个连续的页，创建的表的大小至少是1MB才对啊？其实这是因为在每个段开始时，先用32个页大小的碎片页（fragment page）来存放数据，在使用完这些页之后才是64个连续页的申请。这样做的目的是，对于一些小表，或者是undo这类的段，可以在开始时申请较少的空间，节省磁盘容量的开销。
页 page
在InnoDB存储引擎中，常见的页类型有：
❑数据页（B-tree Node）
❑undo页（undo Log Page）
❑系统页（System Page）
❑事务数据页（Transaction system Page）
❑插入缓冲位图页（Insert Buffer Bitmap）
❑插入缓冲空闲列表页（Insert Buffer Free List）
❑未压缩的二进制大对象页（Uncompressed BLOB Page）
❑压缩的二进制大对象页（compressed BLOB Page）
InnoDB存储引擎是面向列的（row-oriented），也就说数据是按行进行存放的。
data page页默认16kb,当有新索引记录写入时,会预留1/16(1kb)空闲空间用于以后的索引记录写入
InnoDB数据页由以下7个部分组成。
❑File Header（文件头）
❑Page Header（页头）
❑Infimun和Supremum Records
❑User Records（用户记录，即行记录）
❑Free Space（空闲空间）
❑Page Directory（页目录）
❑File Trailer（文件结尾信息）
File Header
记录页的一些头信息
Page Header
记录数据页的状态信息
Infimum和Supremum Record
每个数据页中有两个虚拟的行记录，用来限定记录的边界。Infimum记录是比该页中任何主键值都要小的值，Supremum指比任何可能大的值还要大的值。这两个值在页创建时被建立，并且在任何情况下不会被删除。
User Record 和 Free Space
User Record就是之前讨论过的部分，即实际存储行记录的内容。再次强调，InnoDB存储引擎表总是B+树索引组织的。
Free Space很明显指的就是空闲空间，同样也是个链表数据结构。在一条记录被删除后，该空间会被加入到空闲链表中。
Page Directory
存放了记录的相对位置（注意，这里存放的是页相对位置，而不是偏移量），有些时候这些记录指针称为Slots（槽）或目录槽（Directory Slots）。
由于在InnoDB存储引擎中Page Direcotry是稀疏目录，二叉查找的结果只是一个粗略的结果，因此InnoDB存储引擎必须通过recorder header中的next_record来继续查找相关记录。同时，Page Directory很好地解释了recorder header中的n_owned值的含义，因为这些记录并不包括在Page Directory中。
需要牢记的是，B+树索引本身并不能找到具体的一条记录，能找到只是该记录所在的页。数据库把页载入到内存，然后通过Page Directory再进行二叉查找。只不过二叉查找的时间复杂度很低，同时在内存中的查找很快，因此通常忽略这部分查找所用的时间。
File Trailer
为了检测页是否已经完整地写入磁盘（如可能发生的写入过程中磁盘损坏、机器关机等），InnoDB存储引擎的页中设置了File Trailer部分。
File Trailer只有一个FIL_PAGE_END_LSN部分，占用8字节。前4字节代表该页的checksum值，最后4字节和File Header中的FIL_PAGE_LSN相同。将这两个值与File Header中的FIL_PAGE_SPACE_OR_CHKSUM和FIL_PAGE_LSN值进行比较，看是否一致（checksum的比较需要通过InnoDB的checksum函数来进行比较，不是简单的等值比较），以此来保证页的完整性（not corrupted）。
约束
对于InnoDB存储引擎本身而言，提供了以下几种约束：
❑Primary Key
❑Unique Key
❑Foreign Key
❑Default
❑NOT NULL
约束更是一个逻辑的概念，用来保证数据的完整性，
索引是一个数据结构，既有逻辑上的概念，在数据库中还代表着物理存储的方式。
外键约束
对于数据的导入操作时，外键往往导致在外键约束的检查上花费大量时间。因为MySQL数据库的外键是即时检查的，所以对导入的每一行都会进行外键检查。但是用户可以在导入过程中忽视外键的检查。
分区表
就访问数据库的应用而言，从逻辑上讲，只有一个表或一个索引，但是在物理上这个表或索引可能由数十个物理分区组成。每个分区都是独立的对象，可以独自处理，也可以作为一个更大对象的一部分进行处理。
MySQL数据库的分区是局部分区索引，一个分区中既存放了数据又存放了索引。而全局分区是指，数据存放在各个分区中，但是所有数据的索引放在一个对象中。目前，MySQL数据库还不支持全局分区。
对表空间的概念好模糊啊，怎么看都看不明白
段segment、 区extent、 页page(block)
然后数据页的结构%>_<%
约束
视图
分区
看得比较粗糙，感觉实用性不怎么高呀。
Jeremy Cole - InnoDB
jeremycole/innodb_ruby
innodb_ruby工具分析innob表空间文件Part-01
innodb_ruby工具分析innob表空间文件Part-02
