Mysql架构

image.png

索引

不同的存储引擎，数据文件和索引文件存放的位置是不同的，分为聚簇索引和非聚簇索引。区分聚簇索引和非聚簇索引的关键点在于索引文件和数据是否放在一起。
聚簇索引：数据和索引文件放在一起。
非聚簇索引：数据和索引文件分开。

哈希

哈希表可以完成索引的存储，每次再添加索引的时候需要计算指定列的hash值，取模运算后计算出下标，将元素插入下标位置即可。适合等值查询的场景，表中的数据是无序数据，在进行范围查找时比较浪费时间，需要进行遍历操作。哈希表在使用的时候，需要将全部的数据加载到内存，比较耗费内存空间。

为什么不用其他的树？

在树的结构中，左子树必须小于根节点，右子树必须大于根节点，如果是多叉树从左到右是有序的。

二叉树(不平衡) -> AVL树(平衡二叉树) -> 红黑树

  • 二叉树在插入数据会出现偏坠的情况。
  • AVL树是一个平衡树，最高子树跟最低子树高度差不能超过1.因此在进行元素插入时，会进行1到N次旋转，严重影响插入性能。
  • 红黑树是基于AVL树的升级，损失了部分查询的性能，来提升插入的性能。在红黑树中最低子树跟最高子树只差小于2倍即可，在插入的时候，不需要进行N多次的旋转操作，而且还加入了变色的特性，来满足插入和查询性能的平衡，但随着数据量的增多，树的深度将变的越来越深，查询速度就会收到影响。

    二叉树及其N多的变种都不能支撑索引，原因是树的深度无法控制，或者插入数据的性能较低。


B树(B-树)

  • 所有键值分布在整棵树中
  • 搜索有可能在非叶子节点结束，在关键字全集内做一次查找，性能逼近二分查找
  • 每个节点最多拥有m个子树
  • 根节点至少有2个子树
  • 分支节点至少拥有m/2颗子树(除根节点和叶子节点外都是分支节点)
  • 所有叶子节点都在同一层、每个节点最多可以有m-1个key，并且以升序排列

    每个节点都有key，同事也包含data，而每个页存储空间是有限的，如果data比较大会导致每个节点存储的key数量变小。当存储的数据量很大的时候会导致深度较大，增大查询时磁盘io次数，进而影响查询性能。


B+树

  • B+树每个节点可以包含更多的节点，一是为了降低树的高度，二是将数据范围变为多个区间，区间越多，数据检索越快。
  • 非叶子节点存储key，叶子节点存储key和data
  • 叶子节点两两指针相互连接，符合磁盘的预读特性，顺序查询性能更高

InnoDB引擎

Mysql的InnoDB存储引擎默认会把所有的数据文件放到表空间中(共享表空间)，不会为每一个单独的表保存一份数据文件，如果需要将每一个表单独使用文件保存(独立表空间)。

Mysql5,7版本：
.frm文件：存放表结构的文件
.ibd文件：存放数据和索引的文件

Mysql8.0版本后只有.ibd文件，表结构信息也保存在.ibd文件中。

MyISAM引擎

.frm文件：存放表结构的文件
.myi文件：存放索引的文件
.myd文件：存放数据的文件

Mysql表空间的概念

Mysql调整表空间的参数innodb_file_per_table在mysql5.6.6及其后续版本默认开启。该参数将会影响表结构文件以及数据、索引文件的存储。

查看是否开启

  1. mysql> show variables like '%per_table%';

开启方法

  1. 方式一：在my.cnf中[mysqld]下设置
  2. innodb_file_per_table=1
  4. 方式二：client连接mysql执行：
  5. set global innodb_file_per_table=on;

关闭方法

  1. 方式一：在my.cnf中[mysqld]下设置
  2. innodb_file_per_table=0
  4. 方式二：client连接mysql执行：
  5. set global innodb_file_per_table=off;

共享表空间

  1. 某一个数据库的所有的表数据、索引文件全部放在一个文件中，默认这个共享表空间的文件路径在data目录下。 默认的文件名为：ibdata1  初始化为10M。
  • 优点：可以将表空间分成多个文件存放到各个磁盘上（表空间文件大小不受表大小的限制，如一个表可以分布在不同的文件上）。数据和文件放在一起方便管理。
  • 缺点：所有的数据和索引存放到一个文件中，虽然可以把一个大文件分成多个小文件，但是多个表及索引在表空间中混合存储，这样对于一个表做了大量删除操作后表空间中将会有大量的空隙，特别是对于统计分析，日志系统这类应用最不适合用共享表空间。

独立表空间

  1. 每一个表都将会生成以独立的文件方式来进行存储，每一个表都有一个.frm表描述文件，还有一个.ibd文件。 其中这个文件包括了单独一个表的数据内容以及索引内容，默认情况下它的存储位置也是在表的位置之中。
  • 优点
    • 1.每个表都有自已独立的表空间。
    • 2.每个表的数据和索引都会存在自已的表空间中。
    • 3.可以实现单表在不同的数据库中移动。
    • 4.空间可以回收(除drop table操作处，表空不能自已回收)。
    • 4-1.Drop table操作自动回收表空间，如果对于统计分析或是日志表，删除大量数据后可以通过:alter table TableName engine=innodb;回收不用的空间。
    • 4-2.对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
    • 4-3对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能。
  • 缺点
    • 独立表空间文件增大，不会拆分为多个小文件。

共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。

共享表空间转化为独立表空间

  • 方式一：先逻辑备份，然后修改配置文件my.cnf中的参数innodb_file_per_table参数为1，重启服务后将逻辑备份导入即可。

  • 方式二：修改配置文件my.cnf中的参数innodb_file_per_table参数为1，重启服务后将需要修改的所有innodb表都执行一遍：alter table table_name engine=innodb;使用该方式修改后，原来库中的表中的数据会继续存放于ibdata1中，新建的表才会使用独立表空间


    Mysql缓存机制

  • 缓存数据形式Key-Value，key为查询的SQL

  • 查询缓存在5.7之后版本被移除
  • 使用场景，读多写少，准确说是几乎不怎么写
  • 需要在my.cnf中配置query_cache_type参数(0,1,2)
  • 按需使用缓存：select SQL_CACHE * FROM TABLENAME;
  • 查看缓存运行状态：show status like ‘%xxxxxxx%’

Bin Log(逻辑日志)

  • 二进制日志
  • Binlog在Mysql的Server层实现(引擎公用)
  • Binlog为逻辑日志，记录的是一条语句的原始逻辑
  • Binlog不限大小，追加写入，不会覆盖以前的日志

开启bin-log

  • 查看是否开启：show variables like ‘%log_bin%’; ———— log_bin为on则为开启
  • log-bin=/var/lib/mysql/mysql-bin;
  • mysql5.7及以上版本需配置：server-id=123454

Redo Log(物理日志)

  • 记录innodb存储引擎的事务日志
  • mysql的wal机制(write-ahead-logging)，先写日志再写磁盘
  • 文件名：ib_logfile*

redo log的两阶段提交

Undo Log