InnerDB实现原理
它是MySQL 从5.5 版本卡死的默认的存储引擎, 是第一份支持ACID特性的MySQL存储引擎, 特点是行锁设计, 支持MVCC(多版本并发控制), 支持外键, 提供一致性非锁定读, 同时尽可能高效的利用计算机硬件资源.
MVCC
MVCC( Multiversion Concurrency Control), 即多版本并发控制技术, 它使得大部分支持行锁的事物引擎, 不再单纯的使用行锁来进行数据库的并发控制, 取而代之的是把数据库的行锁与行的多个版本结合起来, 只需要很小的开销, 就可以实现非锁定读, 从而大大提高数据库系统的并发性能
后台线程: Master Thread : 将内存数据异步刷新到磁盘, InnoDB的主要工作都是该线程完成. 该线程具有最高的优先级, 在 DB 运行过程中主要进行两部分操作: 每秒将日志缓冲刷新到磁盘, 合并插入缓冲, 将脏页刷新到磁盘等. IO Thread: 处理 IO 请求回调 Purge Thread: 在事物提交的时候回收Undo Log InnoDB存储阴影是基于磁盘的, 并将其中所有的记录按照页的方式进行管理, 由于CPU和磁盘速度的鸿沟, 采用缓冲池技术来提高数据库的性能 缓存池是一块内存区域, 在DB读取页的时候, 首先从磁盘读到缓存池中, 成为将页 FIX 在缓冲池中, 下次再读相同页的时候, 先判断是否再缓冲池中. 对于写操作, 首先修改缓冲池中的页, 再以一定的频率刷新到磁盘上 InnoDB中缓冲池页的大小默认为16KB, 使用 LRU 算法进行管理. InnoDB 对新读取的页都会放在 midpoint(默认 5/8 长度处) 重做日志缓冲: InnoDB首先将 Redo Log 放在这个缓冲区, 然后以一定的频率刷新到 Redo Log 文件中
数据页 数据页, 操作系统通过机械磁头读取硬盘中的文件, 读取指定的数据之后, 自动读取大约 4KB 的页数据, 将与此数据又换的一并读取, 为了机器性能考虑, 因为在磁盘, 磁道, 扇区中机械查找数据并不容易, 直接读取的数据页为了提升及其效率. 索引页 索引页, MySQL的InnoDB 引擎通过 B+ 实现索引页, 相比B树, 大大减小了树深, 在磁盘中读取数据, 减小读取次数, 有效提升速度, B+树搜索之后并不能直接找到数据, 只能找到索引页, 将该页加载入内存, 通过 key 在其中进行二分查找, 找到 key 对应的 slot, 在 slot 管理的记录中查找最终的数据 插入缓冲 插入缓冲对于提高数据的插入和修改有很大的帮助, 对于非聚集索引的插入或更新操作, 不是每一次直接插入到索引页中, 而是先判断插入的非聚集索引页是否在缓冲池中, 若在, 则直接插入; 若不在, 则先放入到一个 Insert Buffer 对象中; 数据库这个非聚集的索引已经插到叶子节点, 而实际没有, 只是存放在另一个位置. 然后再以一定的频率和情况进行 InsertBuffer 和辅助索引叶子节点的 merge(合并) 操作, 这时通常能将多个插入合并到一个操作中(因为在一个索引页中), 这就大大提高了对于非聚集索引插入的性能. 自适应哈希索引 InnoDB存储引擎会监控对表上各索引页的查询. 如果观察到建立hash索引可以带来速度提升, 则建立哈希索引, 称之为自适应哈希索引(Adaptive Hash Index, AHI). AHI 是通过缓冲池的 B+ 树页构造而来, 因此建立的速度很快, 而且不需要对整张表构建哈希索引. InnoDB存储引擎会自动根据访问的评率和模式来自动的为某些热点页建立哈希索引. 日志文件 错误日志(ErrLog) 错误日志对MySQL的启动, 运行,关闭过程进行了记录, 不仅仅记录了所有错误信息, 也记录了一些警告信息, 遇到问题是应该先查看改文件以便定位问题. 当 MySQL 不能正常启动, 或者 MySQL 在运行期间遇到的内存不足等问题都可以在其中找到详细记录. 慢查询日志(SlowLog) 慢查询日志能够定位到可能存在问题的SQL语句, 可以设定一个阈值, 将运行时间超过该值的SQL语句都记录到慢查询日志文件中. 另一个可用的参数是 log_queries_not_using_indexes, 如果SQL语句没有使用索引, 同样将这条SQL语句记录到慢查询日志文件. 查询日志(QueryLog) 查询日志记录了所有对MySQL请求的信息, 不论是否得到了正确的执行. 默认文件名: 主机名.log 二进制日志 BinLog记录了对MySQL 执行更改的(不包括SELECT 和SHOW 等对数据本身没有修改) 的操作, 不过若一个修改操作本身没有导致数据库发生变化也会被写入 BinLog 中(如修改了一条不存在的记录). 此外, 二进制日志还包括了 DB 修改操作的时间以及其他额外信息, BinLog 主要的用途有: 1. 数据恢复: 某些数据的恢复需要BinLog 2. 集群同步: 通过复制和执行BinLog, 使一台远程的 MySQL 从库与当前主库进行实时同步. 3. 数据同步: 不同于集群同步, 业务场景中经常需要其他组件(搜索引擎, 业务报表等) 需要感知数据库的修改, 此时可以通过同步 BinLog实现. InnoDB表存储 在 InnoDB表中, 表都是根据主键顺序组织存放的, 这种存储方式成为索引组织表, 每张表都有一个主键, 没有显示指定 InnoDB 会使用第一个非空的唯一索引, 如果没有唯一索引, InnoDB 会自动创建一个 6 字节大小的指针作为主键. 所有的数据都被存放在一个表空间(tablespace)中, 表空间又由段(segment), 区(extent), 页(page) 组成. 表空间(Tablespace), 是 InnoDB 存储引擎逻辑存储的顶层对象, 所有数据都存放在表空间, 其中包括数据, 索引, 插入缓冲, 回滚信息, 系统事物信息等. 端(Segment), 表空间是由多个段组成的, 常见的段有数据段, 索引段, 回滚段等. InnoDB 由于索引组织表的特点, 数据即索引, 索引即数据. 因此数据段是 B+树的叶子结点, 索引段是 B+ 树的非叶子节点.回滚段 区(Extent), 是由连续页组成的空间, 在任何情况下每个区的大小都为 1MB, 为了保证中页的连续性, InnoDB 一次从磁盘申请 4-5 个区, 默认情况下, InnoDB 页大小为 16KB, 一个区中一共有 64 个连续的页 页(Page): 是 InnoDB 磁盘管理的最小单位, 默认 16KB, 常见的页有: 数据页 / undo log 页/ 系统等 行(Row): InnoDB 中数据按行进行存放, 每页最多允许存放 16KB /2 -200 = 7992 行记录
InnoDB使用 B+树 1. 文件很大, 不可能全部存在内存中, 所以要存在磁盘上 2. 索引的组织结构要尽量减少查找过程中磁盘 I/O 的存取次数 3. B+树素有的data域都在叶子节点, 一般来都会进行一个优化, 就是将素有的叶子结点用指针串起来, 这样遍历叶子及诶单就可以获得全部数据 标签：缓冲,MySQL,索引,InnoDB,磁盘,原理,InnerDB,日志 From： https://www.cnblogs.com/qiezi777/p/16877926.html