MySQL 物理数据模型

每一行数据都是放在数据页，按数据页为单位把磁盘上的数据加载到内存的缓存页里来，也是按照页为单位，把缓存页的数据刷入磁盘上的数据页中。

表、行和字段是逻辑上的概念，而表空间、数据区和数据页就是物理概念。表空间、数据页这些东西，都对应到了MySQL在磁盘上的一些物理文件。

SQL语句仅指定查询或更新哪个表的哪些数据，怎么知道：

为什么不直接更新磁盘数据？

来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据，必然导致执行请求性能极差。因为磁盘随机读写性能最差，所以MySQL才设计了如此复杂的一套机制，通过内存里更新数据，然后写redo log及事务提交，后台线程不定时刷新内存里的数据到磁盘文件。

这样每个更新请求，尽量就是更新内存，然后顺序写日志文件。更新内存性能极高，然后顺序写磁盘上的日志文件性能也高，因为顺序写磁盘文件，他的性能要远高于随机读写磁盘文件。

执行update之类的 SQL 时，必然涉及到对数据更新，那此时对数据不是直接去更新磁盘文件，而是要把磁盘上的一些数据加载到内存里来，然后对内存里的数据进行更新，同时写redo log到磁盘。

难道每次都是把磁盘里的一条数据加载到内存里去更新，然后下次要更新别的数据时，再从磁盘里加载另外一条数据到内存？

这样每次都是一条条数据加载到内存里更新，效率不高。所以 innodb 引入 数据页 ，即将数据组织成一页页的，每页16K，然后每次加载磁盘数据到内存时，至少加载一页甚至多页数据：

假设执行：

  update xxx set xxx=xxx where id=1

则此时会将id=1这条数据所在的一页数据都加载到内存，这页数据里可能还包含id=2，id=3等数据。

更新完id=1的数据后，接着更新id=2的数据，那此时是不是就不用再读取磁盘里的数据了？因为id=2本就和id=1同页，之前这页数据就已加载到内存，直接更新内存里的数据页中的id=2这条数据即可。

如下就是数据页的意义，磁盘和内存间的数据交换通过数据页来执行，包括内存里更新后的脏数据，刷回磁盘时，也是至少一个数据页刷回去。

我们一直在内存里更新各种数据，当I/O线程把内存里的脏数据刷到磁盘时，也是以数据页为单位刷回。

对一个表，可指定其行存储的格式，比如这里用COMPACT格式：

  CREATE TABLE table_name (columns) ROW_FORMAT=COMPACT ALTER TABLE table_name ROW_FORMAT=COMPACT

建表时，就可指定行存储格式，后续也能修改。

COMPACT行存储格式下，每行数据实际存储时，格式如下：

  变长字段的长度列表，null值列表，数据头，column01的值，column02的值，column0n的值......

对于每行数据，存储时都会有一些头字段对这行数据进行描述，再放上这一行数据每一列具体值，这就是所谓的行格式。