存储引擎

存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的，也可以被成为表类型。

  • 创建表时可以指定存储引擎，在CREATE TABLE语句后面添加ENGINE=存储引擎名
  • 查询数据库支持的存储引擎：SHOW ENGINES;

MySQL体系结构

mysqlStruct

MySQL的服务端是分层实现的：

  1. 连接层：接收客户端连接，完成安全处理，授权和校验权限等操作
  2. 服务层：核心部分，实现SQL接口，解析器，查询优化器，缓存等，所有跨存储引擎的功能也在这一层实现，如过程，函数等
  3. 引擎层：存储引擎负责MySQL中数据的存储和提取的方式，服务器通过API和存储引擎通信。不同的存储引擎有不同的功能
  4. 存储层：存储数据库数据

存储引擎特点

InnoDB

InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，MySQL5.5之后默认的存储引擎为InnoDB

特点：

  • DML操作遵循ACID模型，支持事务
  • 行级锁，提高并发访问性能
  • 支持外键FOREIGN KEY约束，保证数据的完整性和正确性

文件：xxx.ibd，xxx表示表名，InnoDB每张表都会对应这样一个表空间文件，存储表结构（frm，sdi）、数据和索引。

InnoDB的逻辑存储结构

mysql_innodb

MyISAM

MySQL早期的默认存储引擎

特点：

  • 不支持事务，不支持外键
  • 支持表锁，不支持行锁
  • 访问速度快

文件：xxx.MYD、xxx.MYI、xxx.sdi。sdi文件存储表结构信息，MYD文件存放数据，MYI文件存储索引

Memory

表数据存储在内存中，可能会受到硬件问题或断电问题影响，只能将这些表作为临时表或者缓存使用

特点：

  • 存放在内存中，访问速度更快
  • 支持hash索引

文件：xxx.sdi。存储表结构信息

三个存储引擎特点对比

mysql_engineSpecial

存储引擎的选择

  • InnoDB：适合对事务的完整性有较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询外还包括更新、删除操作的场景
  • MyISAM：适合以读和插入操作为主，对事务的完整性、并发性要求不高的场景，可以被MongoDB替代
  • MEMORY：通常作为临时表和缓存，可以被Redis替代

索引

​ 索引是帮助MySQL高效获取数据的有序数据结构。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用数据，可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

​ 索引可以提高数据检索的效率，降低数据库的IO成本，并且通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗。带来好处的同时，索引降低了更新表的速度，对表进行增删改时效率降低，但是在正常业务中，增删改的频率要远小于查询，基本可以忽略这个缺点。

索引结构

MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构，主要包含以下几种：

索引结构 描述
B+ Tree 最常见的索引类型，大部分引擎都支持B+树索引
Hash 使用哈希表实现，只有精确匹配索引列的查询才有效，不支持范围查询。Memory支持该索引
R-tree空间索引 主要用于地理空间数据类型，使用较少，MyISAM的特殊索引类型
Full-text全文索引 通过建立倒排索引，快速匹配文档的方式，类似于Lucene，Solr，ES。InnoDB和MyISAM支持该索引。

平常说的索引一般都是B+ Tree索引

为什么InnoDB存储引擎选择使用B+tree索引

  • 相对于二叉树，层级更少，搜索效率高
  • 相对于B Tree，无论是叶子节点还是非叶子节点，都会保存数据，这会导致一页中存储的键值和指针减少，进而导致树的层级变深，性能降低
  • 相对于Hash索引，B+ Tree支持范围匹配和排序

索引分类

mysql_indexType

在InnoDB中，根据索引的存储形式，又可以分为聚集索引和二级索引：

mysql_InnoDBIndexType

在进行查找时，如果查找的不是主键，则需要先在二级索引找到对应的主键，再去聚集索引找到全部信息，这叫做回表查询。

索引的语法

  • 创建索引：CREATE [UNIUQE|FULLTEXT] INDEX 索引名 ON 表名(字段列表);
  • 查看索引：SHOW INDEX FROM 表名;
  • 删除索引：DROP INDEX 索引名 ON 表名;

SQL性能分析

  • SQL执行频率：MySQL客户端连接成功后，通过show[session|global] status命令可以提供服务器状态信息。

    如：SHOW GLOBAL STATUS LIKE 'Com_______';查看数据库增删改查的使用频率

  • 慢查询日志：记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有SQL语句的日志。

    默认是关闭状态，可以通过sql语句set global slow_query_log=ON;和set long_query_time=x;打开慢查询日志记录和设置慢查询门槛时间

  • profile详情：show profiles能够在做SQL优化时帮助我们了解各种操作耗费时间的详情。

    默认profile是关闭状态，通过set global profiling=1;打开。

    • 查看每一条SQL语句的耗时情况：show profiles;
    • 查看指定query_id的SQL语句各个阶段的耗时情况：show profile for query query_id;
    • 查看指定query_id的SQL语句CPU使用情况：show prifile cpu for query query_id;

  • explain执行计划：可以使用explain或者desc命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。语法为EXPLAIN/DESC + SELECT语句。

    explain各字段的含义：

    • id：表示查询中执行select子句或者是操作表的顺序（id号大的先执行，id相同，执行顺序从上到下）
    • select_type：表示select的类型，常见的取值有simple（简单表，不使用表连接和子查询）、primary（主查询）、union（union后面的查询语句）、subquery（子查询语句）
    • type：表示连接类型，性能由好到差的连接类型为：NULL、system、const、eq_ref、ref、range、index、all
    • possible_key：显示可能应用在这张表上的索引
    • key：实际用到的索引
    • key_len：索引中使用的字节数，索引字段最大可能长度
    • rows：MySQL认为必须要执行查询的行数，估计值
    • filtered：表示返回结果的行数占续读取行数的百分比，值越大越好

索引使用注意事项

  • 遵守最左前缀法则：如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是**在查询时**select语句必须要从建立索引的最左列开始，并且不跳过索引中的列。如果跳过某一列，后面字段的索引将失效。

  • 避免范围查询：在联合索引中，如果出现了范围查询（>、<），范围查询右侧的列索引失效。但是如果使用(>=,<=)则不会失效，所以在查询时尽量使用>=和<=。

  • 避免索引列运算：在索引列上进行运算操作，索引会失效

  • 字符串加引号：如果查询时字符串不加单引号，索引失效

  • 避免头部模糊匹配：使用模糊匹配时，使用尾部模糊匹配，索引不会失效，使用头部模糊匹配时，索引失效

  • or连接：用or关键字分割开的条件，只要有一个条件没有建立索引，所有条件的索引都会失效

  • 数据分布影响：如果MySQL评估使用索引比全表扫描还慢，则不使用索引

  • SQL提示：优化数据库的一个重要手段，在SQL语句中加入一些人为的提示信息来达到优化操作的目的

    • use index(建议使用):EXPLAIN SELECT 字段名 FROM 表名 USE INDEX(索引名) WHERE 条件;
    • ignore index(不要使用):EXPLAIN SELECT 字段名 FROM 表名 IGNORE INDEX(索引名) WHERE 条件;
    • force index(强制使用):EXPLAIN SELECT 字段名 FROM 表名 FORCE INDEX(索引名) WHERE 条件;

  • 尽量使用覆盖索引（需要查找的字段只需要一次索引就能找全，不需要回表），避免select *

  • 前缀索引：当字段类型为字符串时，有时需要索引很长的字符串，可以直将字符串的一部分前缀建立索引，达到节约索引空间，提高效率的效果。

    语法：CREATE INDEX 索引名 ON 表名(字段名(n))其中n是想要建立索引的字段前缀长度

    长度选择：可以通过SELECT COUNT(distinct substring(字段名,1,n))/COUNT(*) FROM 表名;来计算索引性，选择合适的长度，越接近1越好

  • 联合索引：如果存在多个查询条件，针对查询字段建立联合索引可以做到覆盖查询，提高效率。建立联合索引时要注意字段位置

索引设计原则

  1. 数据量较大（大于一百万），且查询比较频繁的表
  2. 针对于常作为查询条件(where)、排序（order by)、分组(group by)操作的字段建立索引
  3. 选择区分度高的列作为索引，建立唯一索引，区分度越高，使用索引的效率越高
  4. 如果是字符串类型的字段，字段的长度较长，可以针对字段建立前缀索引
  5. 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
  6. 要控制索引的数量，只建立有必要的索引，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
  7. 如果索引列不能存储NULL值，需要在创建表时使用NOT NULL约束。这样优化器知道每列是否包含NULL值，可以更好地确定哪个索引更有效

SQL优化

插入数据

  1. 如果需要一次性插入多条数据，可以从三方面进行优化
    • 使用批量插入语句：Insert into test values(1,'name1'),(2,'name2'),(3,'name3');
    • 手动控制事务，全部插入后再关闭事务
    • 主键顺序插入
  2. 如果要大批量插入数据（几百万条），可以使用load指令进行插入
-- 客户端连接服务端加上参数 -–local-infile
mysql –-local-infile -u root -p
-- 设置全局参数local_infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;
-- 执行load指令将准备好的数据，加载到表结构中
load data local infile '/root/sql1.log' into table tb_user fields
terminated by ',' lines terminated by '\n' ;

主键优化

主键顺序插入的性能要高于乱序插入，因为在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表(index organized table，IOT)。

设计原则

  • 满足业务需求的情况下，尽量降低主键的长度
  • 插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键
  • 尽量不要使用UUID做主键或者是其他自然主键，如身份证号
  • 业务操作时，避免对主键的修改

order by优化

MySQL的排序，有两种方式：

  • Using filesort: 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sortbuffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫FileSort排序。
  • Using index: 通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高。

对于以上的两种排序方式，Using index的性能高，在优化排序操作时，尽量要优化为Using index

优化原则

  1. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则
  2. 尽量使用覆盖索引
  3. 多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC。
  4. 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小sort_buffer_size(默认256k)

limit优化

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

优化思路: 一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化。

update优化

当update语句的where条件存在索引时，会使用行锁，锁定这一行的数据，但是当where条件没有索引时，会使用表锁锁住整张表，阻止其他的DML请求，降低效率。

所以update中的where条件尽量选择有索引的列

锁

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除对传统的计算资源（CPU、RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。

MySQL中的锁，按照锁的粒度分，分为三类：

  • 全局锁：粒度最大，锁定数据库中的所有表
  • 表级锁：每次操作锁住整张表
  • 行级锁：粒度最小，每次操作锁住对应的行数据

全局锁

全局锁就是对整个数据库实例加锁，加锁后整个数据库就处于只读状态，后续的DML的写语句，DDL语句，以及更新操作的事务提交语句都将被阻塞

典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

语法

  • 加全局锁
flush tables with read lock;
  • 数据备份
mysqldump -uroot –p1234 test > test.sql
  • 释放锁
unlock tables;

特点

数据库中加全局锁，是一个比较重的操作，存在以下问题：

  • 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆。

  • 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟。

在InnoDB引擎中，可以在备份时加上参数--single-transaction参数来完成不加锁的一致性数据备份。

mysqldump --single-transaction -uroot –p123456 test > test.sql

表级锁

表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。

对于表级锁，主要分为以下三类：

  • 表锁

  • 元数据锁（meta data lock，MDL）

  • 意向锁

表锁

表锁分为两类：

  • 表共享读锁（read lock）：对指定表加读锁后，不会影响其他客户端的读，但是会阻塞其他客户端的写
  • 表共享写锁（write lock）：对指定表加写锁后，会阻塞其他客户端的读和写
语法

加锁：lock tables 表名… read/write

释放锁：unlock tables / 客户端断开连接

元数据锁

元数据锁(meta data lock，MDL)的加锁过程是系统自动控制的，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DM与DDL冲突，保证读写的正确性

这里的元数据，可以简单理解为就是一张表的表结构。也就是说，某一张表涉及到未提交的事务时，不能修改这张表的表结构

当对一张表进行增删改查的时候，加MDL读锁(共享)，当对表结构进行变更操作的时候，加MDL写锁(排他)

常见操作中添加的元数据锁

对应SQL 锁类型 说明
lock tables xxx read/write SHARED_READ_ONLY / SHARED_NO_READ_WRITE
select 、select … lock in share mode SHARED_READ 与SHARED_READ、SHARED_WRITE兼容，与EXCLUSIVE互斥
insert 、update、delete、select … for update SHARED_WRITE 与SHARED_READ、SHARED_WRITE兼容，与EXCLUSIVE互斥
alter table … EXCLUSIVE 与其他的MDL都互斥

意向锁

为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查

当一个客户端在执行DML操作时，会对涉及的行加行锁，同时也会对该表加上意向锁，其他客户端，在对这张表加表锁时，会根据该表上所加的意向锁来判定是否可以成功加表锁，无需逐行判断行锁情况

分类

意向共享锁(IS): 由语句select … lock in share mode添加。与表锁共享锁(read)兼容，与表锁排他锁(write)互斥

意向排他锁(IX): 由insert、update、delete、select…for update添加。与表锁共享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥

事务提交后，意向共享锁、意向排他锁，都会自动释放

行级锁

行级锁每次操作锁住对应的行数据。粒度最小，发生锁冲突的概率最低，并发度最高。应用在InnoDB存储引擎中。

InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：

  • 行锁（Record Lock）：锁定单个行记录的锁，防止其他事务对此行进行update和delete。在读已提交（READ UNCOMMITTED，RC）、可重复读（REPEATABLE READ，RR）隔离级别下支持。

  • 间隙锁（Gap Lock）：锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下支持。

  • 临键锁（Next-Key Lock）：行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。在RR隔离级别下支持。

行锁

InnoDB实现了以下两种类型的行锁：

  • 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁
  • 排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁

其中共享锁之与共享锁兼容，排他锁与其他锁都互斥

常见操作中添加的行锁
对应SQL 锁类型 说明
INSERT … 排他锁 自动加锁
UPDATE … 排他锁 自动加锁
DELETE … 排他锁 自动加锁
SELECT（正常） 不加任何锁
SELECT … LOCK IN SHARE MODE 共享锁 需要手动在SELECT之后加LOCK IN SHARE MODE
SELECT … FOR UPDATE 排他锁 需要手动在SELECT之后加FOR UPDATE

默认情况下，InnoDB在RR事务隔离级别运行，InnoDB使用next-key锁进行搜索和索引扫描，以防止幻读。

  • 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁
  • InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁

查看意向锁及行锁的加锁情况：

select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks;

间隙锁和临键锁

产生条件：

  • 索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁

  • 索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock退化为间隙锁

  • 索引上的范围查询(唯一索引)，会访问到不满足条件的第一个值为止

    比如查询一张表上id >= 20的数据，并添加共享锁，此时会根据数据库表中现有的数据，将数据分为三个部分：[20]、(20, 表中已有的id最大值)、(id最大值,+∞)，数据库在加锁时会在20加行锁，id最大值的临键锁（包含最大值及最大值之前的间隙），正无穷的临键锁(正无穷及之前的间隙)

InnoDB引擎

逻辑存储结构

InnoDB的逻辑存储结构分为表空间、段、区、页、行。

innodb_composition

  1. 表空间：表空间是InnoDB存储引擎逻辑结构的最高层，如果用户启用了参数innodb_file_per_table(在8.0版本中默认开启)，则每张表都会有一个表空间（xxx.ibd），一个mysql实例可以对应多个表空间，用于存储记录、索引等数据

  2. 段：分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段（Rollback segment），InnoDB是索引组织表，数据段就是B+树的叶子节点， 索引段即为B+树的非叶子节点。段用来管理多个Extent（区）

  3. 区：区是表空间的单元结构，每个区的大小为1M。默认情况下，InnoDB存储引擎页大小为16K，即一个区中一共有64个连续的页

  4. 页：页是InnoDB磁盘管理的最小单元，每个页的大小默认为 16KB。为了保证页的连续性，InnoDB 存储引擎每次从磁盘申请4-5个区

  5. 行：InnoDB数据是按行进行存放的。在行中，默认有两个隐藏字段：

  • Trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
  • Roll_pointer：每次对某条引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

架构

MySQL5.5版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，使用广泛。在InnoDB架构图中，左侧为内存结构，右侧为磁盘结构

innodb_frame

内存结构

内存结构部分主要有：Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer

Buffer Pool

InnoDB存储引擎基于磁盘文件存储，访问物理硬盘和在内存中进行访问，速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行磁盘I/O。

在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含了undo页、插入缓存、自适应哈希索引以及InnoDB的锁信息等等。

Buffer Pool是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），然后再以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度。

缓冲池以Page页为单位，底层采用链表数据结构管理Page。根据状态，将Page分为三种类型：

• free page：空闲page，未被使用

• clean page：被使用page，数据没有被修改过

• dirty page：脏页，被使用page，数据被修改过，数据与磁盘的数据不一致，

参数查看：show variables like 'innodb_buffer_pool_size';

Change Buffer

Change Buffer，更改缓冲区（针对于非唯一的二级索引页），在执行DML语句时，如果这些数据Page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区Change Buffer中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。

非唯一的二级索引页是以相对随机的顺序插入二级索引，删除和更新可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有ChangeBuffer之后，可以在缓冲池中进行合并处理，减少磁盘IO

Adaptive Hash Index

自适应hash索引用于优化对Buffer Pool数据的查询。InnoDB中虽然没有直接支持hash索引，但是提供了自适应hash索引。

hash索引在进行等值匹配时，一般性能要高于B+树，因为hash索引一般只需要一次IO，B+树可能需要几次匹配。但是hash索引又不适合做范围查询、模糊匹配等操作。

InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在特定的条件下hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。

自适应哈希索引，无需人工干预，系统根据情况自动完成

参数：adaptive_hash_index

Log Buffer

日志缓冲区用来保存要写入到磁盘中的log日志数据（redo log 、undo log），默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘 I/O

参数:

  • innodb_log_buffer_size：缓冲区大小
  • innodb_flush_log_at_trx_commit：日志刷新到磁盘时机，取值主要包含：
    • 日志在每次事务提交时写入并刷新到磁盘，默认值
    • 每秒将日志写入并刷新到磁盘一次
    • 日志在每次事务提交后写入，并每秒刷新到磁盘一次

磁盘结构

System Tablespace

系统表空间是更改缓冲区的存储区域。如果表是在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等）

参数：innodb_data_file_path

File-Per-Table Tablespaces

每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件中，也就是说，每创建一个表，都会产生一个表空间文件

开关参数：innodb_file_per_table，默认开启

General Tablespaces

通用表空间，在创建表时，可以指定该表空间

  • 创建表空间
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;
  • 创建表空间时制定表
CREATE TABLE xxx ... TABLESPACE ts_name;
Undo Tablespaces

撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储undo log日志。

Temporary Tablespaces

InnoDB使用会话时的临时表空间和全局临时表空间，存储用户创建的临时表等数据。

Doublewrite Buffer Files

双写缓冲区，InnoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据

后台线程

在InnoDB的后台线程中，分为4类，分别是：Master Thread、IO Thread、Purge Thread、Page Cleaner Thread

Master Thread

核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性，还包括脏页的刷新、合并插入缓存、undo页的回收。

IO Thread

在InnoDB存储引擎中大量使用了AIO来处理IO请求, 这样可以极大地提高数据库的性能，而IO Thread主要负责这些IO请求的回调。

线程类型 默认个数 职责
Read thread 4 负责读操作
Write thread 4 负责写操作
Log thread 1 负责将日志缓冲区刷新到磁盘
Insert buffer thread 1 负责将写缓冲区刷新到磁盘

通过指令，查看到InnoDB的状态信息，其中就包含IO Thread信息：show engine innodb status \G;

Purge Thread

主要用于回收事务已经提交了的undo log，在事务提交之后，undo log可能不用了，就由Purge Thread来回收

Page Cleaner Thread

协助Master Thread刷新脏页到磁盘的线程，Page Cleaner Thread可以减轻Master Thread的工作压力，减少阻塞

InnoDB中的事务

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败

  • 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败
  • 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态
  • 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
  • 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

对于这四大特性，其中原子性、一致性、持久性，是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。而隔离性是通过数据库的锁，加上MVCC来保证的

Redo log

重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者在内存中，后者在磁盘中。

当事务提交之后会把所有修改信息都会存到该日志中，用于在刷新脏页到磁盘时，发生错误时，进行数据恢复，以循环方式写入重做日志文件。

有了redolog，对缓冲区的数据进行增删改之后，会首先将操作的数据页的变化记录在redo log buffer中。在事务提交时，会将redo log buffer中的数据刷新到redo log磁盘文件中。过一段时间如果刷新缓冲区的脏页到磁盘时，发生错误，此时就可以借助于redo log进行数据恢复，这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘或者涉及到的数据已经落盘，此时redo log就可以删除了，所以存在的两个redo log文件是循环写的。

MVCC

  1. 当前读

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select … lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读

  1. 快照读

简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读

  • Read Committed：每次select，都生成一个快照读
  • Repeatable Read：开启事务后第一个select语句才是快照读的地方
  • Serializable：快照读会退化为当前读
  1. MVCC

全称Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐藏字段、undo log日志、readView

隐藏字段

数据库中的表在创建之后，查看表结构时可以显式的看到我们制定创建的字段。实际上除了制定创建的字段以外，InnoDB还会自动的添加三个隐藏字段，及其含义分别是：

隐藏字段 含义
DB_TRX_ID 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID
DB_ROLL_PTR 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本
DB_ROW_ID 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段

上表中前两个字段是肯定会添加，最后一个字段DB_ROW_ID，得看当前表有没有主键，如果有主键，不会添加该隐藏字段

undo log

回滚日志，用于记录数据被修改前的信息，作用包含两个: 提供回滚(保证事务的原子性)和MVCC(多版本并发控制)

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚

  • Undo log销毁：undo log在事务执行时产生，在事务提交后，insert产生的undo log日志只在回滚时需要，可被立即删除。update、delete产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即

    删除。

  • Undo log存储：undo log采用段的方式进行管理和记录，存放在rollback segment回滚段中，内部包含1024个undo log segment

版本链

当有多个并发事务在访问同一张表时，每个事务提交的sql语句都会记录undo log日志，记录数据变更之前的样子; 然后更新记录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本

每个并发事务可能都会发起很多次sql请求，最终可以发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undo log生成一条记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录

readview

ReadView（读视图）是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id

包含四个核心字段：

字段 含义
m_ids 当前活跃的事务ID集合
min_trx_id 最小活跃事务ID
max_trx_id 预分配事务ID，当前最大事务ID+1（事务ID是自增的）
creator_trx_id ReadView创建者的事务ID

在readview中规定了版本链数据的访问规则(trx_id代表当前undo log版本链对应事务ID)：

条件 是否可以访问 说明
trx_id == creator_trx_id 可以访问该版本 说明数据是当前这个事务更改的
trx_id < min_trx_id 可以访问该版本 说明数据已经提交
trx_id > max_trx_id 不可以访问该版本 说明该事务是在ReadView生成后才开启
min_trx_id <= trx_id <= max_trx_id 如果trx_id不在m_ids中，是可以访问该版本的 说明数据已经提交

不同的隔离级别，生成ReadView的时机不同：

  • READ COMMITTED：在事务中每一次执行快照读时生成ReadView
  • REPEATABLE READ：在事务中第一次执行快照读时生成ReadView，后续复用该ReadView

MySQL管理

系统数据库

Mysql数据库安装完成后，自带了一下四个数据库，具体作用为：

数据库 含义
mysql 存储MySQL服务器正常运行所需要的各种信息（时区、主从、用户、权限等）
information_schema 提供了访问数据库元数据的各种表和视图，包含数据库、表、字段类型及访问权限等
performance_schema 为MySQL服务器运行时状态提供了一个底层监控功能，主要用于收集数据库服务器性能参数
sys 包含了一系列方便DBA和开发人员利用performance_schema性能数据库进行性能调优和诊断的视图

常用工具

mysql客户端工具

# 语法
mysql [options] [database]
# 选项
-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口
-e, --execute=name #执行SQL语句并退出

-e选项可以在Mysql客户端执行SQL语句，而不用连接到MySQL数据库再执行，可以对于一些批处理脚本

mysqladmin

mysqladmin是一个执行管理操作的客户端程序。可以用它来检查服务器的配置和当前状态、创建并删除数据库等

# 语法
mysqladmin [options] command ...
# 选项
-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口

mysqlbinlog

由于服务器生成的二进制日志文件以二进制格式保存，所以如果想要检查这些文本的文本格式，就会用到mysqlbinlog日志管理工具

#语法
mysqlbinlog [options] log-files1 log-files2 ...
#选项
-d, --database=name #指定数据库名称，只列出指定的数据库相关操作
-o, --offset= # 忽略掉日志中的前n行命令
-r,--result-file=name #将输出的文本格式日志输出到指定文件
-s, --short-form #显示简单格式,省略掉一些信息
--start-datatime=date1 --stop-datetime=date2 #指定日期间隔内的所有日志
--start-position=pos1 --stop-position=pos2 #指定位置间隔内的所有日志

mysqlshow

mysqlshow客户端对象查找工具，用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引

# 语法
mysqlshow [options] [db_name [table_name [col_name]]]
# 选项
--count # 显示数据库及表的统计信息（数据库和表均可以不指定）
-i # 显示指定数据库或者指定表的状态信息

mysqldump

mysqldump客户端工具用来备份数据库或在不同数据库之间进行数据迁移。备份内容包含创建表，及插入表的SQL语句

# 语法
mysqldump [options] db_name [tables]
mysqldump [options] --database/-B db1 [db2 db3...]
mysqldump [options] --all-databases/-A
# 连接选项
-u, --user=name # 指定用户名
-p, --password[=name] # 指定密码
-h, --host=name # 指定服务器ip或域名
-P, --port= # 指定连接端口
# 输出选项
--add-drop-database # 在每个数据库创建语句前加上drop database语句
--add-drop-table # 在每个表创建语句前加上drop table语句，默认开启;(不开启 (--skip-add-drop-table))
-n, --no-create-db # 不包含数据库的创建语句
-t, --no-create-info # 不包含数据表的创建语句
-d --no-data # 不包含数据
-T, --tab=name # 自动生成两个文件：一个.sql文件，创建表结构的语句；一个.txt文件，数据文件

mysqlimport/source

  • mysqlimport是客户端数据导入工具，用来导入mysqldump加 -T 参数后导出的文本文件
mysqlimport [options] db_name textfile1 [textfile2...]
  • source

如果需要导入sql文件，可以使用mysql中的source指令

source /root/xxxxx.sql