mysql之innodb存储引擎---数据存储结构

1.1文件组织架构

首先看一下mysql数据系统涉及到的文件组织架构，如下图所示：

 msyql文件组织架构图

从图看出：

1、日志文件：slow.log(慢日志)，error.log(错误日志)，general.log(基本日志)

2、配置文件：my.cnf

3、数据库：performance_schema，mysql，information_schema，sys

4、innodb存储引擎（框中部分）,主要包括有：两个日志文件ib_logfile0和ib_logfile1，由参数innodb_log_file_size控制大小，innodb_log_files_in_group控制个数。userdb是用户创建的数据库，其中各有三个表，t1,t2,t3，并分别对应三个.frm文件。但是可以只有一个ibd文件，由参数innodb_file_per_table控制，表示是否启用单独的表空间。其中t1表是单独的表空间，t2和t3使用共享表空间。db.opt是msyql的一些配置信息，如编码，排序等。

1.2 系统表 

 由于msyql是插拔式数据库，分为server层和存储引擎层，server层只有一个，而存储引擎有多种，所以这两者需要相互配合，由于最早的存储引擎MyISAM没有定义系统表，只有.frm文件，导致了后面的存储引擎也没有像Oracle一样查看系统表。其实Innodb有四个系统表：SYS_TABLES,SYS_COLUMNS,SYS_INDEXES,SYS_FILES

SYS_TABLES：存储所有以Innodb为存储引擎的表SYS_COLUMNS：存储innodb表的所有列SYS_INDEXES：存储innodb表中的索引信息SYS_FILES：存储innodb表中索引中定义的所有列

二、表空间

首先看一下innodb的逻辑存储结构，如图所示：

 innodb逻辑存储结构

     从innodb逻辑存储结构看，所有的数据都被逻辑的存放在一个空间中，为表空间（tablespace）。表空间又由段（segment）、区（extend）、页（page）组成，页也可以别成为块（block）。

    表空间为innodb存储引擎的存储结构的最高层，所以数据都放在表空间中。默认的表空间为ibdata1。如果设置了参数innodb_file_per_table，则每个表可以cun存放在单独的表空间。只有数据，索引，插入缓冲Bitmap页存放在单独的表空间，回滚信息，插入缓冲索引页，系统事务信息，二次写缓冲还是存放在共享表空间中。

    注意：innodb存储引擎在rollback时去收缩共享表空间，不会回收这些空间，但是会自动判断这些undo页是否还需要，如果不需要，则标记为可用空间，供下次undo页使用。

三、段

   段是表空间文件中的主要组织结构，它是一个逻辑概念，用来管理物理文件，是构成索引、表、回滚段的基本元素。

  上图中显示了表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等。InnoDB存储引擎表是索引组织的（index organized），因此数据即索引，索引即数据。那么数据段即为B+树的页节点（上图的leaf node segment），索引段即为B+树的非索引节点（上图的non-leaf node segment）。

   创建一个索引（B+树）时会同时创建两个段，分别是内节点段和叶子段，内节点段用来管理（存储）B+树非叶子（页面）的数据，叶子段用来管理（存储）B+树叶子节点的数据；也就是说，在索引数据量一直增长的过程中，所有新的存储空间的申请，都是从“段”这个概念中申请的。在内节点分裂时申请新节点就在内节点段申请，在叶子节点分裂时申请新节点，就在叶子段申请。

四、簇/区

     已知一个索引由两个段组成，段是个逻辑概念，innodb引入了簇的概念，在代码中被称为extent；

    簇是段的基本构成单位，一个段可由多个簇构成，一个簇是物理上连续分配的一段空间。每一个段至少会有一个簇，在创建一个段时会创建一个默认的簇。如果存储数据时，一个簇已经不足以放下更多的数据，此时需要从这个段中分配一个新的簇来存放新的数据。一个段所管理的空间大小是无限的，可以一直扩展下去，但是扩展的最小单位就是簇。

   簇的大小是固定的（1M=64*16k）。簇默认是由64个连续的页组成的，每个页大小为16KB。可以通过参数innodb_page_size修改页的大小，这样一个簇中的页的数量必定会增多（必须保证一个簇的大小为1M）

 五、页

    页是簇的组成单位，也是段所管理的最小单位，数据文件管理的最小单位，也是文件空间分配的最小单位。

    在逻辑上（页面号都是从小到大连续的）及物理上都是连续的。在向表中插入数据时，如果一个页面已经被写完，系统会从当前簇中分配一个新的空闲页面处理使用，如果当前簇中的64个页面都被分配完，系统会从当前页面所在段中分配一个新的簇，然后再从这个簇中分配一个新的页面来使用。

常见的页类型有：数据页（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）

段、簇、页的关系图如下：

 段、簇、页关系图

六、段、簇、页组织结构

    一个表空间可以有多个文件，每个文件都有各自的编号，创建一个表空间时，至少有一个文件，这个文件被称为“0号文件”。一个文件是被切割为等长“默认16KB”的块，这个块通常被称为页面，那么在“0号文件”的第一个页面（page_no为0）中，存储了这个表空间中所有段簇也管理的入口，那么在这个页面存储的数据就是16KB，但通常会有页面头信息会占用一些空间，真正的管理信息数据是从页面偏移为fil_page_data(38)的位置开始的，这个位置存储了表空间的描述信息，具体内如如下：

FSP_SPACE_ID：该文件对应的spaceidFSP_NOT_USED：如其名，保留字节，当前未使用FSP_SIZE：当前表空间总的PAGE个数，扩展文件时需要更新该值（fsp_try_extend_data_file_with_pages）FSP_FREE_LIMIT：当前尚未初始化的最小PageNo。从该Page往后的都尚未加入到表空间的FREELIST上。FSP_SPACE_FLAGS：当前表空间的FLAG信息FSP_FRAG_N_USED：FSP_FREE_FRAG链表上已被使用的Page数，用于快速计算该链表上可用空闲Page数FSP_FREE：当一个Extent中所有page都未被使用时，放到该链表上，可以用于随后的分配（空闲簇）FSP_FREE_FRAG：FREE_FRAG链表的BaseNode，通常这样的Extent中的Page可能归属于不同的segment，用于segmentfragarraypage的分配（半满簇）FSP_FULL_FRAG：Extent中所有的page都被使用掉时，会放到该链表上，当有Page从该Extent释放时，则移回FREE_FRAG链表（满簇）FSP_SEG_ID：当前文件中最大SegmentID+1，用于段分配时的segid计数器FSP_SEG_INODES_FULL：已被完全用满的InodePage链表FSP_SEG_INODES_FREE：至少存在一个空闲InodeEntry的InodePage被放到该链表上

具体的结构请看图：

InnoDB 表空间page管理

  上图中，在InnoDB里链表头称为FLST_BASE_NODE，大小为FLST_BASE_NODE_SIZE(16个字节)。BASE NODE维护了链表的头指针和末尾指针，每个节点称为FLST_NODE，大小为FLST_NODE_SIZE（12个字节）

     表空间控制信息中有：满簇链表，半满簇链表，空闲簇链表，而段的Inode中也有满簇链表，半满簇链表，空闲簇链表，但是他们是不同的，表空间中的链表管理是整个表空间中所有的满簇链表，半满簇链表，空闲簇链表，而段的Inode信息中管理的是属于自己断种的满簇链表，半满簇链表，空闲簇链表，当段申请一个新簇时，如果段上没有空闲簇，这样就会去表空间的簇上找，找到后从相应的链表中摘下来给段所用。

      数据文件的第一个Page类型为FIL_PAGE_TYPE_FSP_HDR，在创建一个新的表空间时进行初始化(fsp_header_init)，该page同时用于跟踪随后的256个Extent(约256MB文件大小)的空间管理，所以每隔256MB就要创建一个类似的数据页，类型为FIL_PAGE_TYPE_XDES 。

      XDES Page除了文件头部外，其他都和FSP_HDR页具有相同的数据结构，可以称之为Extent描述页（簇描述页），一个XDES Page最多描述256个Extent每个XDES PAGE最多存储256个XDES Entry，每个Entry占用40个字节（簇描述符），描述64个Page（即一个Extent）格式如下：

XDES_ID：如果该Extent归属某个segment的话，则记录其ID，8个字节XDES_FLST_NODE：(FLST_NODE_SIZE)维持Extent链表的双向指针节点，12字节XDES_STATE：该Extent的状态信息，包括：XDES_FREE，XDES_FREE_FRAG，XDES_FULL_FRAG，XDES_FSEG，4字节XDES_BITMAP：总共16*8= 128个bit，用2个bit表示Extent中的一个page，一个bit表示该page是否是空闲的(XDES_FREE_BIT)，另一个保留位，尚未使用XDES_CLEAN_BIT），16字节

      段由簇构成，段通过三个链表将不同状态的簇连接管理起来，链表是双向的，链表头分别为：FSEG_FREE,FSEG_FULL,FSEG_NOT_FULL,链表节点就是簇，每个簇被一个簇描述符管理。一个簇描述符，占用40B的空间，这些信息是被存储在页面中，这个页称为簇描述页，它存储的内容叫簇描述符。在Innodb中，一个簇描述页默认管理16834个页面，簇的大小默认为64个页，而一个簇描述符为40B，所以一个簇描述页中有16834/64=256个簇。其中256*40B空间用来存储簇描述符，关系图如下：

    其实第一个簇（其实是第一个页面）只是用来做簇描述页的，没有被加入到表空间的簇链表中，也没有假如段的簇链表中。真正的簇使用是从第二个开始的，实际只有255个簇可以被使用。

整体组织架构图如下：

上图描述了表空间、Inode页面、Inode、段、簇、页面之间的关系，也是Innodb文件系统的管理架构图。

参考：

《msyql运维内参》

《mysql技术内幕：Innodb存储引擎》

http://mysql.taobao.org/monthly/2016/02/01/

mysql之innodb存储引擎---数据存储结构

标签：http   用户   bitmap   指针   ext   extend   user   必须   大小   

小编还为您整理了以下内容，可能对您也有帮助：

Innodb存储表结构

在InnoDB存储引擎中，表都是根据主键顺序组织存放的，这种存储方式的表叫索引组织表。在InnoDB存在引擎表中，每张表都有个主键(Primary key)，如果在创建表时没有显示定义主键，则会按照如下方式选择或者创建主键：

(1) 判定是否有非空的唯一索引(unique not null)，如果有则该列即为主键。若果有多个，则选择建表是第一个定义的非空位于索引为主键。注意:主键的选择根据的是定义索引的顺序，而不是建表时的列的顺序。

(2) 如果不存在唯一索引，InnoDB存储引擎字段创建一个6字节大小的指针(仅内部可见)。

在InnoDB存储引擎中，所有的数据都被逻辑地存放在一个空间中，称之为表空间(tablespace)。表空间又由段(segment)、区(extent)、页(page)组成。InnoDB存储引擎的逻辑存储结构如下图。

表空间 可以看见InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。表空间又分为表空间和共享表空间。通过参数innodb_file_per_table参数来决定使用何种类型的表空间。但是需要注意的是表空间内只存放 数据、索引和插入缓冲页 ，其他的数据，如回滚(undo)信息、插入缓冲索引页、系统事务信息、二次写缓冲(double write buffer)等还是放置在原来的共享表空间中。

段 表空间由各个段组成。常见的段有数据段、索引段、回滚段等。InnoDB存储引擎是索引组织表，因此数据即索引，索引即数据。数据段即为B+树的叶子点(leaf node segment)，索引段为B+数据的非索引节点(non-leaf node segment)。回滚段比较特殊以后在介绍。段都是引擎自身管理的。

区 区是由连续页组成的空间。InnoDB存储引擎页的大小为16KB，一个区有64个连续的页组成，所以每个区的大小都是 1MB 。参数 innodb_page_size 可设置页的大小4K、8K，但是，不论页的大小怎么变化，区的大小不变1M。但是有这样一个问题：在开启表空间之后，创建的表默认大小是 96K ，区中是64个连续的页，创建的表空间应该是1M才对呀？这是因为在每个段的开始时，先用 32个页 大小的碎片页(fragment page)来保存数据，在使用完这些页之后才是64个连续的页的申请。这样做是对于一些小表或者undo这类的段，可以在开始时申请较少的空间，节省磁盘容量的开销。

页 页是InnoDB磁盘管理的最小单位。默认大小为16K，可以通过innodb_page_size将页的大小设置为4K、8K、16K，则所有表中页的大小都为设置值，不可以对其再次修改。除非通过mysqlmp导入和导出操作来产生新的库。常见的页的类型有:数据页(B-tree Node)、undo页(unod Log Page)、系统页(System Page)、事务数据页(Transaction system Page)、插入缓冲空闲列表页(Insert Buffer Free List)、未压缩的二进制大对象页(Uncompressed BLOB Page)、压缩的二进制对象页(compressed BLOB Page)。

行 InnoDB存储引擎是面向行的(row-oriented)，也就是说数据是按行进行存放的。每个页存放的行记录也是有硬性定义的，最多运行存放（16K/2-200）行的记录，即7992行记录。

InnoDB表由共享表空间（ibdata1），redo日志文件组（ib_logfile0，ib_logfile1），表结构定义文件（表名.frm）组成。当开启表空间时，还有以 表名.ibd 的文件，存储数据，索引，插入缓存列。

InnoDB存储引擎的记录是以行的形式存储的，这就表明页中保存着表中一行行的数据。其类型有REDUNDANT、 COMPACT、COMPRESS、DYNAMIC四种。可以通过 show table status 。

COMPACT 在MySQL 5.0中引入，其设计目标是高效的存储数据。也就是一个页中存放的行数据越多，其性能越高。compact行记录的存放方式:

REDUNDANT

行溢出数据

Compressed和Dynamic行记录格式

CHAR的行存储结构

File Header：文件头

Page Header：页头

Infimum和Supremum Record

User Record和Free Space

Page Directory：页目录

File Trailer：文件结尾信息

MySQL-InnoDB表 -

MySQL InnoDB存储引擎之表(一)_chenlvzhou的专栏-CSDN博客

mysql的innodb数据库引擎详解

一．mysql体系结构和存储引擎

1.1、数据库和实例的区别

数据库：物理操作系统或其他形式文件类型的集合。在mysql下数据库文件可以是frm，myd，myi，ibd结尾的文件。

数据库实例：由数据库后台进程/线程以及一个共享内存区组成。数据库实例才是真正用来操作数据库文件的。

mysql数据库是单进程多线程的程序，与sql server比较类似。也就是说，Mysql数据库实例在系统上的表现就是一个进程。

1.2、mysql的体系结构

mysql由连接池组件、管理服务和工具组件、sql接口组建、查询分析器组件、优化器组件、缓存组件、插件是存储引擎、物理文件。

1.3、mysql存储引擎

1.3.1、innodb存储引擎，特点支持外键、行锁、非锁定读(默认情况下读取不会产生锁)、mysql-4.1开始支持每个innodb引擎的表单独放到一个表空间里。innodb通过使用MVCC来获取高并发性，并且实现sql标准的4种隔离级别，同时使用一种被称成next-key locking的策略来避免换读(phantom)现象。除此之外innodb引擎还提供了插入缓存(insert buffer)、二次写(double write)、自适应哈西索引(adaptive hash index)、预读(read ahead)等高性能技术。

1.3.2、myisam存储引擎，myisam特点是不支持事物，适合olap应用，myisam表由MYD和MYI组成。mysql-5.0版本之前，myisam默认支持的表大小为4G，从mysql-5.0以后，myisam默认支持256T的表单数据。myisam只缓存索引数据。

1.3.3、NDB存储引擎，特点是数据放在内存中，mysql-5.1版本开始可以将非索引数据放到磁盘上。NDB之前的缺陷是join查询是mysql数据库层完成的，而不是存储引擎完成的，复杂的join查询需要巨大的网络开销，速度很慢。当前mysql cluster7.2版本中已经解决此问题，join查询效率提高了70倍。

1.3.4、memeory存储引擎，将数据放到内存中，默认使用hash索引，不支持text和blob类型，varchara是按照char的方式来存储的。mysql数据库使用memory存储引擎作为临时表还存储中间结果集(intermediate result)，如果中间集结果大于memorg表的容量设置，又或者中间结果集包含text和blog列类型字段，则mysql会把他们转换到myisam存储引擎表而放到磁盘上，会对查询产生性能影响。

1.3.5、archive存储引擎，压缩能力较强，主要用于归档存储。

1.3.6、federated存储引擎，不存储数据，他指向一台远程mysql数据库上的表。

1.3.7、maria存储引擎，myisam的后续版本,支持缓存数据和索引，行锁设计，支持mvcc，支持事务和非事务安全的选项，以及更好的BLOG字符类型的处理性能。

1.3.8、其他存储引擎，sphinx用于全文索引，infobright用于数据仓库。

1.4连接Mysql

1.4.1、TCP/IP：基于网络的连接，连接进行权限检查。

1.4.2、命名管道和共享内存：Windows系统上同一服务器上的两进程可通过命名管道连接，需在配置文件中启用--enable-named-pipe选项。

1.4.3、Unix套接字：客户端与服务端位于同一服务器时才可使用，可以在my.cnf中指定-socket=/tmp/mysql.sock，连接时指定./mysql -S/tmp/mysql.sock。

二．InnoDB存储引擎

2.2、innodb引擎架构

InnoDB的多个内存块组成了内存池，负责如下工作：

1).维护所有进程/线程需要访问的多个内部数据结构。

2).缓存磁盘上的数据，方便快速的读取，并且在对磁盘文件的数据进行修改之前在这里缓存。

3).重做日志缓存。

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存是最近的数据，此外、将已经修改的数据文件刷新到磁盘文件

2.2.1、后台线程

innodb存储引擎后台有7个线程，—–4个IO线程(insert buffer thread,log thread,read thread,write thread)，1个master thread，一个lock监控线程，一个错误监控线程。

2.2.2、内存

innodb存储引擎内存由以下三个部分组成：缓冲池(buffer pool),重做日志缓存(redo log buffer),额外的内存池(additional memory pool)。可以使用 show engine innodb status来查看innodb_buffer_pool的使用情况。

innodb_buffer_pool_size：具体看，缓冲池中的数据库类型有：索引页、数据库页、undo页、插入缓存页(insert buffer)、自适应hash(adaptive hashindex)、innodb存储的锁信息(lock info)、数据字典信息(data dictionary)。

InnoDB工作方式：将数据文件按页(每页16K)读入InnoDBbuffer pool，然后按最近最少使用算法(LRU)保留缓存数据，最后通过一定频率将脏页刷新到文件。

2.3、master thread

2.3.1、master thread源码分析

2.3.2、master thread的潜在问题

1、由于硬件的发展，现在的硬件性能已经提高了很多，如果innodb每秒最大刷新100个脏页，那么效率会很低，为了解决这个问题，innodb plugin提供了一个参数innodb_io_capacity，用来表示磁盘IO的吞吐量，默认值是200，规则如下：在合并插入缓存时，合并插入缓存的数量为innodb_io_capacity的5%；在从缓冲区刷新脏页时，啥新脏页的数量为innodb_io_capacity。

2、关于innodb_max_dirty_pages_pct值的争议，如果值过大，内存也很大或者服务器压力很大，那么效率很降低，如果设置的值过小，那么硬盘的压力会增加，建议是在75-80.并且innodb plugin引进了innodb_adaptive_flushng(自适应的刷新)，该值影响每秒刷新脏页的数量。

2.4、关键特性,为innodb提高性能的技术

2.4.1、插入缓存

当一个表有非聚集索引时，对于非聚集索引的叶子节点的插入不是顺序的，这时候需要离散的访问非聚集索引页，性能就在这里降低了，这是由于b+树的原理导致的。插入缓存就是用来解决这个问题的。

对于非聚集索引的插入和更新操作，不是每一次都直接插入索引页，而是先判断插入的非聚集索引页是否在缓存中，如果在就直接插入，如果不在就放入到一个插入缓冲区中，好似欺骗数据库这个非聚集索引已经插入到叶子节点了。然后再以一定的频率插入缓存和非聚集索引页字节点的合并操作。

插入缓存的使用需要满足以下两个条件(也就是非唯一的辅助索引)：索引是辅助索引；索引不是唯一的。

2.4.2、两次写

两次写给innodb带来的是可靠性，主要用来解决部分写失败(partial page write)。在应用重做日之前，我们需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页，再进行重做，这就是doublewrite。

doublewrite有两部分组成，一部分是内存中的doublewrite buffer，大小为2M，另外一部分就是物理磁盘上的共享表空间中联系的128个页，即两个区，大小同样为2M。当缓冲池的张也刷新时，并不直接写硬盘，而是回通过memcpy函数将脏页先拷贝到内存中的doublewrite buffer，之后通过doublewrite buffer再分两次写，每次写入1M到共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘。

2.4.3、自适应哈西索引

由于innodb不支持hash索引，但是在某些情况下hash索引的效率很高，于是出现了 adaptive hash index功能，innodb存储引擎会监控对表上索引的查找，如果观察到建立hash索引可以提高性能的时候，则自动建立hash索引。

2.5、启动、关闭、恢复

innodb_fast_shutdown影响InnoDB表关闭。该参数有0、1、2三个参数。

0 MySQL关闭时 完成所有的full purge和merge insertbuffer操作

1默认值 只将缓冲池内的一些脏页刷新至磁盘

2将日志都写入日志文件不会有任何事务丢失但下次启动时会进行recovery

innodb_force_recovery影响整个innodb存储引擎的恢复状况，该值默认为0，表示当需要恢复时，需要执行所有的恢复操作，当不能进行有效恢复时，如数据页发生了corruption，mysql数据库可能宕机，并把错误写入错误日志中。

三．文件

3.1参数文件

Mysql实例可以不需要参数文件，这是所有的参数值取决于编译Mysql时指定的默认值和源代码中指定参数的默认值。其参数文件是Mysql.cnf。

3.1.1、什么是参数

参数是一个键/值对。可以使用show variables like命令查看，也可以通过information_schema的GLOBAL_VARIABLES视图来查找。

3.1.2、参数类型

参数文件分为两类：动态参数和静态参数。动态参数意味着你可以在Mysql实例运行中进行更改；静态参数说明在整个实例生命周期内都不得进行更改，好像是只读的。对于动态参数，又可以分为global和session关键字，表明该参数的修改是基于当前会话还是真格实例的生命周期。有些动态参数只能在会话中进行修改，如autocommit；有些参数修改完后，在整个实例生命周期中都会生效，如binlog_cache_size；而有些参数既可以在会话又可以在整个实例的生命周期内生效，如read_buffer_size。

3.2、日志文件

3.2.1、错误日志

错误日志对Mysql的启动、运行、关闭过程进行了记录。出现Mysql不能正常启动时，第一个必须查找的文件应该就是错误日志文件。使用show variables like ‘log_error’来定位文件。

3.2.2、慢查询日志

慢查询能为SQL语句的优化带来很好的帮助。设定一个阀值，将运行时间超过该值的所有SQL语句都记录到慢查询日志文件中。用参数long_query_time来设置。另一个参数log_queries_not_using_indexes，若运行的SQL语句没有使用索引，则这条SQL语句会被记录下来。

3.2.3、查询日志

查询日志记录了所有对Mysql请求的信息，不论这些请求是否得到正确的执行。默认文件名为：主机名.log。

3.2.4、二进制日志

二进制记录了对数据库执行更改的所有操作，但是不包括SELECT和SHOW操作，还包括了执行时间和更改操作时间。可用来恢复某些数据，同时也可以用来复制同步远程数据库。将binlog_format设置成row，可以支持事务隔离级别为READ COMMITTED，以获得更好的并发性。在使用MIXED格式下，mysql采用STATEMENT格式进行二进制日志文件的记录，但是有一些情况下会使用ROW格式，可能的情况如下：

1、表的存储引擎为NDB，这个时候DML操作都会以ROW格式记录。

2、使用了uuid()、user(),current_user(),found_rows(),row_count(),等不确定函数。

3、使用了insert delay语句

4、使用了用户定于的函数(UDF)

5、使用了临时表(temporary table)

注意：针对系统库mysql里面的表发生变化的处理规则如下：

1、 如果采用insert，update，delete直接操作表，则日志根据binlog_format设定的格式记录。

2、 如果使用grant，revoke，set password等DCL语句，那么无论如何都会使用SBR模式记录。

3、 blockhole引擎不支持row格式，ndb引擎不支持statement格式。

3.3、套件字文件

Unix系统下本地连接Mysql可以采用Unix套接字方法，需要一个套接字文件，可以使用show variableslike ‘socket’查询。

3.4、pid文件和表结构定义文件

pid文件是实例启动是记录自己进程ID号的文件，表结构定义文件是以frm为后缀名的文件，还可以用来存放视图的定义。

3.5、innodb引擎文件

3.5.1、表空间文件

默认表空间文件为ibdata1文件innodb_data_file_path存储数据，innodb_file_per_table可以按表分别产生一个表空间.db文件，但仅存该表的数据索引和插入缓冲等信息，其他信息如undo信息，系统事务信息，double write buffer等还是存放在默认表空间(ibdata1或表空间组)里。

3.5.2、重做日志文件

redo log是在实例或者介质失败的时候，用来保证数据完整性。每个innodb存储引擎至少有一个重做日志组,每个重做日志文件组下至少又2个重做日志文件，如默认的ib_logfile0、ib_logfile1.为了得到更高的可靠性，你可以设置多个重做镜像日志组。

因为重做日志条目先被写到日志缓冲中，然后根据一定条件刷新到磁盘重做日志文件中。与redo log相关的就是innodb_flush_log_at_trx_commit的值，对innodb的性能影响很大。他有0，1，2三个值，0代表提交事务时，并不同步写redo log，而是等master threas每秒写。1代表commit的时候就将redo log缓存写入磁盘，2代表commit的时候将redo log缓存异步的写入磁盘。

Innodb 和 MyIsam 两种存储引擎的文件存储结构

Myisam 更适合读取大于写入的业务，同时不支持事物。支持全文搜索。

Innodb 支持事物，效率上比myisam稍慢。不支持全文搜索。

Myism物理文件结构为：

.frm文件： 与表相关的 元数据信息 都存放在frm文件， 包括表结构的定义信息等 。

.myd文件： myisam存储引擎专用，用于存储myisam 表的数据

.myi文件： myisam存储引擎专用，用于存储myisam表的 索引相关信息

Innodb的物理文件结构为：

.frm文件： 与表相关的 元数据信息 都存放在frm文件， 包括表结构的定义信息等 。

.ibd文件和.ibdata文件：

这两种文件都是存放innodb数据的文件，之所以用两种文件来存放innodb的数据，是因为innodb的数据存储方式能够通过配置来决定是使用 共享表空间 存放存储数据，还是用 独享表空间 存放存储数据。

独享表空间 存储方式使用.ibd文件，并且每个表一个ibd文件

共享表空间 存储方式使用.ibdata文件，所有表共同使用一个ibdata文件

觉得使用哪种方式的参数在mysql的配置文件中 innodb_file_per_table

关于删除了数据之后，物理文件大小并没有变化的解释

删除之后还有碎片，通过OPTIMIZE TABLE 命令来进行表优化。这个命令可以将表中的空间碎片进行合并，并且可以消除由于删除或者更新造成的空间浪费 。OPTIMIZE TABLE 命令只对 MyISAM 、 BDB 和 InnoDB 表起作用 。