专栏首页CDN及云技术分享innodb存储引擎原理
原创

innodb存储引擎原理

一、 什么是存储引擎

存储引擎位于文件系统(各种数据,二进制形式)之上,各种管理工具(连接池、语义分析器、优化器、缓存区、SQL接口)之下。

图一、mysql体系结构

二、存储引擎功能设计

2.1 功能丰富性(或者SQL语义支持):

事务(和文件系统的最大区别),锁的粒度(行或者表),全文索引,簇索引,外键(这是什么)

2.1.1 事务:

事务的隔离性由锁实现,其他ACD由redo log和undo logo实现。redo log保证事务原子性(怎么理解?由于数据库设计是先写redo,再执行真正修改数据页。所以redo一定是个完整的事务,才会修改数据页)和持久性(怎么理解?持久化到硬盘)。undo log保证事务一致性(数据冲突时的恢复)。

redo 写法是数据库一直顺序写,无需读。由于没有使用O_DIRECT裸写盘,所以每次写redo 必须fsync到硬盘。

另外这里还有提到的是binlog,区分的是binlog是数据库容灾的范筹(记录的是sql语句,在事务提交的时候才会写)。而redo是innodb产生的(修改页的物理二进制日志,随事务进行而并发写)。而且在写redo是以日志块大小和磁盘扇区一样。都是512字节。所以重写日志写入具有原子性。redo的物理二进制日志,以不记录sql语句执行过程,而记录sql执行后的页结果。由此具有幂等性(执行多次等同于执行一次,分布式网络的不可靠 由于多次重新调用接口,必须保证幂等性)。

一个问题是,基于硬盘的数据库会把数据写在内存中,同时对数据库的修改最初也是改在内存上,怎么落地呢(checkpoint检查点机制)。事务数据库为了保证ACID的D一般会使用先写redo log,在修改页。

undo帮助事务回滚和MVCC功能。

2.1.2 表锁、行锁:

锁机制分为latch(轻量级的锁,分为mutex和rwlock。这个是内部锁机制,保证并发线程操作临界资源的正确性,通常没有死锁检测机制, 比如查看mutex的方法是show engine innodb mutex;)和lock(粒度为事务,可以是表、页、行,有死锁检测机制)。

死锁检测机制有:顺序获取多个锁(latch只有这个机制),waits-for graph(图死锁检测),过期机制。

MVCC机制(解决锁带来争用的分布式并发访问问题)

自增长锁:给每个插入赋予一个唯一增加的id,每个插入获取到这个id,就可以释放表锁。通过减少锁的持有时间,提高并发插入效率。

查看当前事务隔离级别:

mysql> SELECT @@tx_isolation\G;
*************************** 1. row ***************************
@@tx_isolation: REPEATABLE-READ

幻读和脏读:脏读都不好吗?在slave节点可以修改innodb的默认事务隔离级别REPEATEDLY READ为READ UNCONMITTED,允许读到不那么准确的数据。

不可重复读:一般不可重复读是可以接受的,因为他读到的是提交的数据,而脏读是读到未提交的数据。如Oracle和SQL Server设置的事务隔离级别是READ CONMIITTED,则会出现不可重复读现象。

丢失更新:一个事务更新会被另一个事务更新所覆盖,从而产生数据不一致。基本数据库任何隔离级别,不会产生。

2.1.3 外键:

2.2 数据存储设计:

支持B树索引,支持hash索引,数据压缩存储,数据表缓存(或者只索引缓存),数据文件加密,存储效率,内存消耗,硬盘消耗,块插入速度,查询缓存,MVCC(解决并发数据一致性问题)。

2.2.1 B+树索引/自适应hash索引:

B树(Blance树或者平衡树):关系型数据库最常用拿来做索引的。从AVL(平衡二叉树演化而来)。

B+树=B树+索引顺序访问。包含树枝节点和叶子节点。所有的数据放在叶子节点。每一个叶子节点互相有序顺序连接。树根节点指引着查找到叶子节点的路径。由于不断的插入和删除,同时B+树会通过旋转保持平衡。

B+索引本身并不是找到具体的一条记录,而是找到该记录所在的页。数据页把载入到内中,然后通过页目录在进行二叉查找。因为在内存查找很快。

聚集索引:按照表的主键构建的B+树。

辅助缩影:叶子节点存放的不是数据,而是捷径,指引到找到所有数据的地方。

数据的区分度:Cardinality

自适应哈希索引:innodb根据查找频度,创建hash索引。将o(logn)的查找复杂度提高最快o(0)(最慢o(n))的速度。哈希索引不对范围查找有效。

全文索引:

2.2.2 压缩空间和加密安全

记录在文件可以是普通模式或者reduction模式。

2.3 容灾机制:

备份机制,备份恢复(备份快照点记录)。热备,冷备,温备。

新上一台备机的备份顺序是记住当前主数据库的LSN(log squence number),导出主数据库的当前数据库并在备机导入。设置LSN同步点

二、innodb特性

2.1 特性

  • innodb架构:多线程模型(Master,IO,Purge,Page Cleaner),数据刷新到硬盘才是sql(事务)执行完的标志吗。purge是完成事务提交后情况undo log。
  • 内存的消耗大(大在哪里?)。内存消耗在具体在缓冲区。缓冲区除了保护有数据页,索引页,还有undo页,插入缓冲。自适应hash索引、锁信息、字典信息。为什么innodb的内存会比其他的存储引擎大呢?查看innodb引擎的内存脚本:https://github.com/lumanyu/niu-command/blob/master/show_memory_usage.sh
  • 什么是数据库实例(类似于服务器的进程,数据库是数据文件)
  • 缓冲区的基本管理思路是LRU。37为距离LRU追加尾部的37%位置,并且只有在mid位置当超过block_times的时候才要可以会被移到mid的热点。当然用户预估自己的热点数据,适当得增加mid之前的热点区域。其中page made young和page not made young就表示了页从old移到new或者由于block_time的限制,old没能移到new。从information_schema数据库的select * from innodb_buffer_pool_stats\G;可以获取到。可以看到这里还是很多old往new的迁移过程当中被block住。(我觉得这里made yong的过程中,是不是有很多热点数据,有没有必要把mid位置调长些)。第一个实例:缓冲区空间size:8192*16K=128M。LRU表项用DATABASE_PAGES表示。FREE_BUFFERS是可利用的页。
  • 主线程:每秒钟循环和每10秒钟循环
  • 重做日志的LSN(Log Sequeence Number)标记版本。
  • Sharp Checkpoint和Fuzzy Checkpoint(主线程定时的刷新,LRU页不够必须删除尾巴页,重做日志不可用,脏页太多)
  • 数据库的容灾:重做日志+LRU。LRU溢出需要写磁盘。重做日志由于磁盘空间必须部分删除需要写磁盘

2.2 innodb关键特性:

  • 插入缓冲:针对非聚集索引的插入或者更新。针对非唯一辅助索引。
  • 两次写:写的压力大不大,总共写内存多少Innodb_dblwr_pages_written(真实反映数据库的),硬盘持久化多少次Innodb_dblwr_writes
  • 自适应hash索引:要求访问模式比较单一
  • AIO:AIO的好处和坏处。:| innodb_flush_neighbors | 1 |
  • 刷新邻接页(预读)。但是如果是本来 就是iops比较高的存储设备还需要这个吗,因为这个是对机械硬盘相邻数据写入做优化,或者有没有可能领接页写入刷新了 又很快变为脏页

三、查看当前数据库运行性能(一些命令)

show global status like 'com_select';列出 自数据库启动以来的所有连接
图3.1

查看数据库的线程数据来窥探性能

图3.2
查看缓存区状态
innodb查看

LRU查看

mysql> show variables like '%old_block%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| innodb_old_blocks_pct  | 37    |
| innodb_old_blocks_time | 1000  |
+------------------------+-------+

查看当前数据库的运行状态还有:

show engine innodb status。
show variables;
show status;

备份相关:

show binlog events in 'bin-log.000004'\G
show master status
show slave status
show binary logs;查看所有的二进制日志
show variables like '%sync_binlog%'
binlog文件转换
每次服务器启动都开启一个新的二进制日志。文件大小超过限制将会创建一个新的文件。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 破解数据孤岛壁垒,三篇论文详细解读联邦学习

    AI 科技评论按:香港科技大学讲席教授、微众银行首席人工智能官(CAIO)杨强教授是机器学习领域内活动积极的学者,也是大家非常熟悉的机器学习研究人员之一。

    AI科技评论
  • 一份 SpringBoot 学习清单

    美码师
  • Mysql客户端任意文件读取学习

    最近打了 DDCTF和 国赛,发现都考了一个知识点,也就是 MysqlLocalInfile客户端文件读取这个漏洞,下面来详细的学习一个这个漏洞。

    安恒网络空间安全讲武堂
  • 一名Java大佬跳槽之旅,离开京东,14面面试经验和收获

    先和boss们打了招呼,然后请假专心面试,2周内请假了6天左右时间,敲定了offer。

    美的让人心动
  • MySQL GTID的管理模式

    从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的...

    jeanron100
  • 永远不要在 MySQL 中使用“utf8”

    最近我遇到了一个 bug,我试着通过 Rails 在以“utf8”编码的 MariaDB 中保存一个 UTF-8 字符串,然后出现了一个离奇的错误:

    程序猿DD
  • oracle批量新增更新数据

    本博客介绍一下Oracle批量新增数据和更新数据的sql写法,业务场景是这样的,往一张关联表里批量新增更新数据,然后,下面介绍一下批量新增和更新的写法:

    用户1208223
  • 编程中,有哪些好的习惯一开始就值得坚持?

    在项目的开始阶段,不要上手直接写代码,一定要先确定代码的分层和架构。该分层和架构在一定程度上决定了未来整个项目的代码风格和维护性,对于项目的长期维护,代码架构的...

    java思维导图
  • 通俗易懂:如何设计能支撑百万并发的数据库架构?

    相信看到这个标题,很多人的第一反应就是:对数据库进行分库分表啊!但是实际上,数据库层面的分库分表到底是用来干什么的,其不同的作用如何应对不同的场景,我觉得很多同...

    JackJiang
  • 保持 WordPress 安全性有效措施汇总

    有关 WordPress 安全性的文章其实已经有很多了,但是明月感觉随着技术的迭代发展, WordPress 安全也在不断的面临考验,好在 WordPress ...

    明月云服务

扫码关注云+社区

领取腾讯云代金券