【MySQL进阶】MySQL架构 索引深度解析

目录

• 1. mysql深度解析
  • 1.1. mysql架构解析
  • 1.2. mysql存储引擎
• 2. 索引
  • 2.1. MySQL索引系统
    • 2.1.1. 问题
    • 2.1.2. InnoDB的索引
  • 2.2. 索引分类
    • 2.2.1. 分类
    • 2.2.2. 索引解析
    • 2.2.3. 索引失效
• 3. 日志系统

---

1. mysql深度解析

参考:

1. MySQL深度解析：mysq|架构体系、mysql调优、mysql索引、索引优化、存储引擎、B+树

---

1.1. mysql架构解析

• MySQL架构
  

• 存储类型

  1. 行式存储
  2. 列式存储

1. 语句

   -- 查看搜索引擎
   show engines;
   
   

2. 其他:

   1. 查询缓存在8.0版本之后取消; --数据不更新的可以放在缓存中;

---

1.2. mysql存储引擎

• 优化步骤
  1. 连接器
  2. 优化器
     1. 索引 – explain中查看查询的种类 type: const system ref range all;
        1. 关注的列: key key_len rows
        2. extra列: using where ; using index 等等;

---

2. 索引

• 索引的实现
• 分类等

---

2.1. MySQL索引系统

2.1.1. 问题

• 问题:
  1. 索引文件是在文件中还是在内存中?
     索引不许进行持久化存储, 除了 memory 这种存储引擎;
  2. 索引在进行数据读取的时候, 需要返回什么信息?
     1. 反应在 IO 上, 读取的次数和量级;
     2. key值 文件名称 offset --hive采用这种格式;
  3. 为什么mysql不使用这种格式?
     1. 拓展:
        1. OLTP: 联机事务处理: 关系型数据库: 时效性高;
        2. OLAP: 联机分析处理: 数据仓库: 对历史数据分析, 产生决策性影响;
     2. 因为慢
  4. 那mysql如何设计索引系统?
     1. 数据格式: k-v
     2. 数据结构: hash 树
  5. mysql采用什么样的数据结构, 为什么?
     1. hash b树
     2. 使用什么数据结构跟 存储引擎 是相关的;
        1. innodb, myisam 使用的是 b树(实质上是 B+树); 同时 innodb支持自适应hash; --无法控制
        2. memory存储引擎使用hash数据结构;
  6. 为什么 hash不行?
     1. 需要良好的 hash算法;
     2. hash表 需要大量内存;
     3. 不适合范围查询; 不适合大量查询的业务场景;
  7. 树 行不行?
     1. bst avl 红黑树 B树 B+树
     2. 为什么使用 B+树?
        1. 二叉树 每次都需要比较;
        2. BST树: 二叉搜索树, 左右大小有序: 缺: 递增递减时, 形成链表, 遍历查询(n);
        3. avl树: 是二叉平衡树: 重新计算根节点,保持树的平衡: 缺: 每次平衡, 导致性能消耗;
        4. 红黑树: 也是二叉平衡树: 其最长路径/最短路径不超过两倍, avl树不超过1; 缺: 数据过多, 导致树高过深, 增加 I/O 次数;
        5. B 树: 一行存放多个记录; --设置Max.degree的值;
     3. 考虑因素:
        1. 局部性原理: 空间和时间, 数据程序聚集存放;
        2. 磁盘预读: 内存跟磁盘进行交互的时候, 有一个最小的逻辑单元, 即 页; 4k或8k; innodbDB 默认读取16k;
           show variables like %innodb_datapage_size%; --innodb_page_size 16384

  -- 查看索引类型
      show index from table;
  

2.1.2. InnoDB的索引

1. InnoDB是通过 B+树 结构对 主键 创建索引, 然后叶子节点中存储记录,

   1. 如果没有主键, 那么会选择 唯一键,
   2. 若没有 唯一键, 那么会生成一个 6字节row_id 来作为主键;

2. 如果创建索引的键 是其他字段, 那么在叶子节点中存储的是该记录的主键,

   1. 然后在通过主键索引找到对应的记录, 叫做回表;

3. 聚簇索引和非聚簇索引

   1. 聚簇索引: 数据和索引 是放在一起的;
   2. 一个表的聚簇索引一定是主键索引吗? 不一定
   3. 一个表的聚簇索引会有很多个吗? 只有一个
   4. 主键索引一定是聚簇索引吗? 假如说创建表的时候没有主键, 没有唯一键, 添加数据之后设置了主键, 会发生什么?
      1. innodb 是主键聚簇, myisam 非聚簇;
      2. innodb的普通列是非聚簇;
      3. 添加 主键, 会重新建立聚簇索引; 大数据量需要一定的时间;
         1. 解析ibd文件可以看到;

4. 注意:

   1. 索引并不是越多越好, 应该选择合适的字段;

---

2.2. 索引分类

2.2.1. 分类

1. 分类

   1. 聚簇索引与非聚簇索引

2. 分类

   1. 主键索引
   2. 唯一索引
   3. 普通索引 辅助索引 二级索引 ==> 回表 和 索引覆盖
   4. 全文索引
   5. 组合索引 联合索引

2.2.2. 索引解析

• 索引分类
  

2.2.3. 索引失效

1. 表达式: id+1=7
2. 函数导致
3. 数据类型的隐式转换: 111 和 '111'
4. or and 要具体分析, 不一定导致索引失效; --explain分析

注意:

1. 可以适当建立组合索引, 实现索引覆盖, 避免回表;

---

3. 日志系统