Innodb存储引擎简介

InnoBD存储引擎

 

innodb内存数据对象：

 

 

插播一条新闻：

ysql> ? set

Name: 'SET'

Description:

Syntax:

SET variable_assignment [, variable_assignment] ...

 

variable_assignment:

     user_var_name = expr

   | [GLOBAL | SESSION] system_var_name = expr

   | [@@global. | @@session. | @@]system_var_name = expr

 

@@global.system_var_name  修改的是全局变量

@@session.system_var_name   修改的是会话级别的变量

@@system_var_name修改的是会话级别的变量

 

显示全局|会话变量：

show [global| session] variables like“system_var_name”;

解释：

    global  显示全局变量

    session    显示会话级别变量

    如果什么都不加，比如：show variables like “storage_engine”，表示显示会话级别变量。

 

 

 

 

如何设置innodb为默认存储引擎—两种办法：

 

方法一：修改全局变量

1.1在MySQL中设置全局变量（在MySQL实例整个生命周期有效）：

注意，这是后创建的表对象，在5.1版本中（其他版本未测试）还是myISAM表，原因是绘画级别默认的存储引擎还是myISAM，下面一步是更改会话级别的存储引擎

1.2 设置会话级别的默认存储引擎

 

 

方法二：修改配置文件

在配置文件中永久设置—重启MySQL生效，比较生硬。

 

 

3.5 INNODB存储引擎的关键特性

1. 设计遵循ACID模型，支持事物，拥有从服务崩溃中恢复的能力，能够最大限度的保护用户的数据。
2. 支持行级锁（Row level locking），并且引入类似oracle中的一致性读特性(mysql中叫MVCC---锁和undo实现)，以提升多用户并发时的读写性能
3. 支持主键索引（primary key），通过主键查找数据时性能极为优异
4. 对于服务器软硬件导致的宕机，不必担心数据损坏，MySQL服务在启动时能够自动进行故障恢复
5. innoDB拥有自己独立的缓存池（对应innodb_buffer_pool_size系统变量）常用数据（含索引都在缓存中）

 

ACID模型：

A，atomicity原子性；

C，consistency 一致性；

I，isolation 隔离性；

D，duration 持续性

 

1. A，atomicity原子性；原子性指整个数据库事物是不可分割的工作单位。只有事物中所有的操作都成功，才算这个事物成功。事物中任何一个SQL语句执行失败，已经执行成功的语句也必须撤销，数据状态应该退回到事物执行前的状态。比如取款的这样的一个过程就应该视为原子操作，即要么都做，要么都不做
2. C，consistency 一致性；指的是事物将数据库从一种一致的状态转变为下一种一致的状态。在事物开始前和事物结束之后，数据库的完整性约束没有被破坏。例如，在表中有一个字段为姓名，为唯一约束。如果一个事物对姓名字段进行了修改，但是在事物提交或事物操作发生回滚后，表中的姓名变得非唯一了，这就破坏了事物的一致性要求，即事物从一种一致的状态变为了一种不一致的状态。因此事物是一致性的单位，如果事物中某个动作失败了，系统可以自动撤销事物---返回之前的状态
3. I，isolation 隔离性；隔离性还有其他的称呼，如并发控制（concurrency control）、可串行化（serializablity）、锁（locking）。事物的隔离性要求每个读写事物的对象对其他事物的操作能相互分离，即该事物提交前对其他事物都不可见，通常这是用锁来实现。
4. D，duration 持续性。事物一旦提交，其结果就是永久的。即使发生宕机等故障，数据库也能将数据恢复。但注意，只能从事物本身的角度来保证结构的永久性，如果是一些外部原因，如raid卡损坏、自然灾害等原因造成的数据库问题，那么所提交的事物可能会有丢失。因此持久性保证事物的高可靠性（High Reliability）,而不是高可用性（High Availability）。

 

 

 

 

innodb存储引擎特点

***存储能力          64TB

***MVCC           YES

B-tree索引           YES

***外键约束          YES

查询缓存          YES

索引缓存          YES

数据缓存          YES

数据压缩          YES

***事物              YES

***锁粒度         行锁

复制              YES

备份、时间点恢复  YES

 

相对于读取速度来说，写入较慢—redo log保证数据可靠性

 

3.6 innodb的逻辑存储结构

innoDB的逻辑存储结构，从大到小分成了4种粒度：

 

1. 页（Page，也叫块），是innodb中最小管理单位。同一个MySQL数据库，不管它分成多少个表空间，所有表空间页大小都相同，默认情况下，页大小16KB，目前只能在源代码层修改，可选值4KB，8KB，16KB

 

1. 区（Extent，也叫扩展）。每个区固定1MB大小，由64个16KB的页组成，或者128个8KB的页，或者256个4KB的页组成

 

 

1. 段（Segment），段本身有很多种，比如像数据段、索引段、回滚段。Segment由无数个Extent组成，当表空间的空闲空间即将用尽，需要扩展时，innodb会先分配32个Pages，之后如果还有空间需求，每次扩展会分配一个完整的Extent给段。

 

1. 表空间（Tablespace）。Innodb逻辑存储单元中最高粒度。默认情况下innodb引擎只对应一个表空间，即系统表空间。所有innodb表的数据（包含索引都存储在该表空间中。注意，仅仅是保存数据，表对象的结构仍然需要保存在与表对象同名的.frm文件中）。这种方式的优点是便于管理，只需要关注系统表空间对应的少数几个文件即可，不过缺点也很明显，数据量很大时管理成本会上升：系统表空间的数据文件扩展后无法回缩，就是说，即使使用truncate，甚至该表空间内实际已经没有存储任何数据，已分配的空间仍然仅是相对于innoDB可用，而不能被操作系统再分配给其他文件使用。

 

下面演示的是innodb表被truncate后，系统表空间没有被操作系统收回。

 

    考虑到这种情况，可以使用独立表空间，就是一个表对象拥有一个独享的.ibd  数据文件，它有以下优点：各表对象的数据独立存储在不同的文件中，可以   更灵活的分散I/O；当执行truncate/drop删除表对象时，空间可以即时释放   回操作系统层。但是不管innodb_file_per_table怎样设置，系统表空间是必    须要有的，innodb自身需要使用系统表空间来存储数据字典及undo日志等。

 

系统表空间

    innoDB系统表空间可以对应多个物理文件，都对应哪些文件，可以通过系统变量innodb_data_file_path来设置的，该变量语法如下：

    innodb_data_file_path=datafile_spec1[:datafile_spec2]

    每个datafile_spec对应一个数据文件，在具体设置时可以指定文件名、文件大小和扩展支持，完整语法如下：

    file_name:file_size:[autoextend[max:max_file_size]]

1. file_name        指定数据文件名
2. file_size        指定文件大小
3. autoextend           指定是否可自动扩展，默认一次扩展8MB的空间，这个大小可以通过innodb_autoextend_increment系统变量指定
4. :max:max_file_size   指定该数据文件最大可占用空间

    具体设置文件大小时，支持K/M/G单位，但要注意的是虽然说innodb不会限制数据文件的大小，但是操作系统自身可能会对此有所限制，如ext4文件系统支持的单个文件最大16TB（最大文件系统为1EB；ext3单个文件为2TB，最大文件系统为16TB）

    innodb_data_file_path=ibdate01.df:2048:autoextend:max:100G

    如果要指定更多数据文件，相互之间可以用“;”隔开

    

    来看一下innodb数据文件存放在哪里，默认存放在/var/lib/mysql/data下，并可以通过innodb_data_home_dir设置

 

 

独立表空间

    是否启用独立表空间，由系统变量innodb_file_per_table来控制，两个值1为启用，0为不启用

编辑配置文件（因为5.1中它是只读变量，只能通过修改配置文件重启生效）：

进入MySQL中查看：

    

创建一个innodb表

看到t6表有单独的表空间

 

3.7 配置innodb日志文件---redo log

    默认情况下，在innodb存储引擎数据目录下会有两个名为ib_logfile0、ib_logfile1的文件，官方叫做innodb存储引擎的日志文件，不过更准确的说应该叫做重做日志文件（redo log file）.为什么强调是重做日志文件呢？是因为重做日志文件对于innodb存储引擎至关重要，他们记录了对于innodb引擎的事物日志。

    当实例失败时，比如MySQL服务器突然掉电导致实例失败，innodb存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。

    相关变量：

1. innodb_log_group_dir    指定redo log存放路径，默认innodb_data_home_dir目录中
2. innodb_log_file_size指定redo log大小，默认是5MB，每个文件最大不超过512GB。本参数会影响到检查点的频率以及故障恢复时间。

       Checkpoint技术解决以下问题：

1. 缩短数据库恢复时间。当数据库宕机时，数据库不需要重做所有的日志，因为checkpoint之前的页都已经刷新汇磁盘。所以数据库只需要对checkpoint后的重做日志进行恢复，这样就大大节省了恢复的时间
2. 缓冲池不够用是将脏页刷新到磁盘。根据LRU算法会移除最近最少使用的页，若此页为脏页，那么需要强制执行checkpoint，将脏页刷新汇磁盘
3. 重做日志不可用时，刷新脏页。因为当前事物数据库系统对重做日志的设计都是循环使用的，并不是让其无限增大。

1. innodb_log_file_in_groups   用于指定日志文件组的数量，默认（最少）是2个，最多不超过100个。

 

介绍一下undo log

对于事物操作来说，有提交（commit）就必然会有回滚（rollback）。提交好理解，就是确定保存写入的数据，那么回滚就要麻烦一些，因为它代表着两个步骤：首先撤销刚刚做的修改，而后将数据恢复至修改前的状态。那么，数据已经写入，怎么恢复到修改前的状态呢？最简单的方式，当然就是在修改前先将旧数据保存下来，保存下的这部分数据用专业术语形容，就是undo日志，存储在系统分配的回滚段中。

 

如要启用事物支持，有两种方式：

1. 禁用事物的自动提交功能由系统变量autocommit控制，0（off）为禁用自动提交，将事物的提交与回滚控制交与前端用户来控制。

 

1. 显式声明事物