mysql innodb的重要组件汇总

innodb包涵如下几个组件

一、innodb_buffer_pool:

它主要用来缓存数据与索引(准确的讲由于innodb中的表是由聚集索引组织的,所以数据只不是过主键这个索引的叶子结点)。

二、change buffer:

  1  如果更新语句要更新二级索引的记录,但是记录所在的页面这个里面并没有在innodb_buffer_pool中,innodb会把这个对二级索引

  面页的更新动作缓存到innodb_buffer_pool的一个特定区域(change buffer);等到之后如果有别的事务B要去读这个二级索引页的时候,

  由于页面还没有,在innodb_buffer_pool中所以B事务会先把页面载入innodb_buffer_pool,这样子目标页面就算进入innodb_buffer_pool了,

  接下来就可根据change buffer的内容来更新索引页面了。这样可以节约IO操作,提高性能。

  2  当然别的刷新机(把change buffer中的变更落盘)制也是有的,比如说当mysql比较空闲的时候,slow shutdown 的过程当中也会刷新

  change buffer中的内容到磁盘

  3  监控change buffer

show engine innodb status;

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 24635311
Log flushed up to 24635311
Pages flushed up to 24635311
Last checkpoint at 24635302
0 pending log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

三、自适应hash索引:

  1  如果表中的某些行会非常频繁的用到,由于innodb表是B+树组织起来的这一特性,最好的情况下innodb也是先读索引页,再读数据页,然后

  找到数据;hash索引是用B+树索引的hash为键,以B+树索引的值(指向的页面)为值的;由于有了hash索引的引入,innodb可以通过计算索引的hash

  值就直接定位到数据所在的页面;所以对于非范围查找的情况下hash索引这样的处理方式是有优势的。

  2  要想innodb能用上bash索引还要有几个条件1、innodb_adaptive_hash_index=1 这样innodb就会启用hash索引了;然而这只是完成了一半,

  innodb并不是为表中的所有行建立hash索引的,只是表中频繁访问的行才会为它建立hash索引,为冷数据建立hash索引是一种浪费;

  innodb_adaptive_hash_index_parts 可以设置hash索引的分区,这种可以提升并发度。

四、redo log buffer:

  redo log buffer 中的内容会被定期的刷新到磁盘,如果redo log buffer 设置的比较大它有利于mysql对大事务的处理,原因在于在大事务的处理中

  可以把redo 写入到redo log buffer 而不是写入到磁盘,由于内存比磁盘快,所以大事务的处理速度上也会比较快;也就是说redo log buffer 比较大

  的情况下在commit 之前可以减少一些没有必要的刷磁盘操作。

五、系统表空间:

  innodb 系统表空间中包涵如下内容:innodb 数据字典,一些存储区域如 doublewrite\changebuffer\undolog ,如果innodb_file_per_table

  没有打开那么那么用户建的表就会保存到这个系统表空间中,这种情况下系统表空间也就可以看面它包涵共享表空间了。

以上就是mysql innodb的重要组件汇总的详细内容,更多关于mysql innodb组件的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL InnoDB如何保证事务特性示例详解

    前言 如果有人问你"数据库事务有哪些特性"?你可能会很快回答出原子性.一致性.隔离性.持久性即ACID特性.那么你知道InnoDB如何保证这些事务特性的吗?如果知道的话这篇文章就可以直接跳过不看啦(#^.^#) 先说结论: redo log重做日志用来保证事务的持久性 undo log回滚日志保证事务的原子性 undo log+redo log保证事务的一致性 锁(共享.排他)用来保证事务的隔离性 重做日志 redo log 重做日志 redo log 分为两部分:一部分是内存中的重做

  • 简述MySQL InnoDB存储引擎

    前言: 存储引擎是数据库的核心,对于 MySQL 来说,存储引擎是以插件的形式运行的.虽然 MySQL 支持种类繁多的存储引擎,但最常用的当属 InnoDB 了,本篇文章将主要介绍 InnoDB 存储引擎相关知识. 1. InnoDB 简介 MySQL 5.5 版本以后,默认存储引擎就是 InnoDB 了.InnoDB 是一种兼顾了高可靠性和高性能的通用存储引擎.在 MySQL 5.7 中,除非你配置了其他默认存储引擎,否则执行 CREATE TABLE 不指定 ENGINE 的语句将创建一个

  • MySQL Innodb 存储结构 和 存储Null值 用法详解

    背景: 表空间:INNODB 所有数据都存在表空间当中(共享表空间),要是开启innodb_file_per_table,则每张表的数据会存到单独的一个表空间内(独享表空间). 独享表空间包括:数据,索引,插入缓存,数据字典.共享表空间包括:Undo信息(不会回收<物理空间上>),双写缓存信息,事务信息等. 段(segment):组成表空间,有区组成. 区(extent):有64个连续的页组成.每个页16K,总共1M.对于大的数据段,每次最后可申请4个区. 页(page):是INNODB 磁盘

  • 获取 MySQL innodb B+tree 的高度的方法

    前言 MySQL 的 innodb 引擎之所以使用 B+tree 来存储索引,就是想尽量减少数据查询时磁盘 IO 次数.树的高度直接影响了查询的性能.一般树的高度在 3~4 层较为适宜.数据库分表的目的也是为了控制树的高度.那么如何获取树的高度呢?下面使用一个示例来说明如何获取树的高度. 示例数据准备 建表语句如下: CREATE TABLE `user` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `name` varchar(100) CHARAC

  • MySQL MyISAM 与InnoDB 的区别

    区别: 1. InnoDB支持事务,MyISAM不支持,对于InnoDB每一条SQL语言都默认封装成事务,自动提交,这样会影响速度,所以最好把多条SQL语言放在begin和commit之间,组成一个事务: 2. InnoDB支持外键,而MyISAM不支持.对一个包含外键的InnoDB表转为MYISAM会失败: 3. InnoDB是聚集索引,使用B+Tree作为索引结构,数据文件是和(主键)索引绑在一起的(表数据文件本身就是按B+Tree组织的一个索引结构),必须要有主键,通过主键索引效率很高.但

  • 详解MySQL(InnoDB)是如何处理死锁的

    一.什么是死锁 官方定义如下:两个事务都持有对方需要的锁,并且在等待对方释放,并且双方都不会释放自己的锁. 这个就好比你有一个人质,对方有一个人质,你们俩去谈判说换人.你让对面放人,对面让你放人. 二.为什么会形成死锁 看到这里,也许你会有这样的疑问,事务和谈判不一样,为什么事务不能使用完锁之后立马释放呢?居然还要操作完了之后一直持有锁?这就涉及到 MySQL 的并发控制了. MySQL的并发控制有两种方式,一个是 MVCC,一个是两阶段锁协议.那么为什么要并发控制呢?是因为多个用户同时操作 M

  • MySQL启动报错问题InnoDB:Unable to lock/ibdata1 error

    在OS X环境下MySQL启动时报错: 016-03-03T00:02:30.483037Z 0 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 35 2016-03-03T00:02:30.483100Z 0 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files. 终端不断地重

  • MySQL InnoDB row_id边界溢出验证的方法步骤

    背景 跟同学聊到row_id一个边界问题,这里详细说明下. InnoDB表若没有定义主键,会使用系统的一个默认递增row_id (dict_sys->row_id)作为主键.每次插入一行加1,到达最大值循环复用. 需要注意的是,虽然dict_sys->row_id 被定义为一个unsigned long long, 但由于这个主键值只有6个字节,因此最大值是2^48. row_id超过这个值还是会递增,只是写入的时候只取低位,可以认为是做取模操作. 问题 这就涉及到一个问题,一个长期运行的My

  • MySQL学习(七):Innodb存储引擎索引的实现原理详解

    概述 在数据库当中,索引就跟树的目录一样用来加快数据的查找速度,对于一个SQL查询操作,根据索引快速过滤掉不符合要求的数据并定位到符合要求的数据,从而不需要扫描整个表来获取所需的数据. 在innodb存储引擎中,主要是基于B+树来实现索引,在非叶子节点存放索引关键字,在叶子节点存放数据记录或者主键索引(或者说是聚簇索引)中的主键值,所有的数据记录都在同一层,叶子节点,即数据记录直接之间通过指针相连,构成一个双向链表,从而可以方便地遍历到所有的或者某一范围的数据记录. B树,B+树 B树和B+树都

  • MySQL slow_log表无法修改成innodb引擎详解

    背景 从mysql.slow_log 获取慢查询日志很慢,该表是csv表,没有索引. 想添加索引来加速访问,而csv引擎不能添加索引(csv引擎存储是以逗号分割的文本来存储的),只能改存储引擎来添加索引了 mysql.slow_log表能改成myisam,不能改成innodb mysql> set global slow_query_log=off; Query OK, 0 rows affected (0.00 sec) mysql> alter table mysql.slow_log e

  • Mysql InnoDB和MyISAM区别原理解析

    mysql支持很多表类型的表(即存储引擎),如myisam.innodb.memory.archive.example等.每种存储引擎都有自己的优点和缺点,充分的理解每种存储引擎,有助于合理的使用它们.有人认为在同一个数据库中使用多种存储引擎很影响性能,其实这是一种十分错误的想法.实际上,除非是非常简单的数据库,否则的话,只使用一种存储引擎,对应用程序的性能来说是一个十分糟糕的行为.对数据库了解的人会根据每张表的作用不同来选择适当的存储引擎,这才是正确的做法. 前面说过mysql的存储引擎很多,

  • MySQL InnoDB中的锁机制深入讲解

    写在前面 数据库本质上是一种共享资源,因此在最大程度提供并发访问性能的同时,仍需要确保每个用户能以一致的方式读取和修改数据.锁机制(Locking)就是解决这类问题的最好武器. 首先新建表 test,其中 id 为主键,name 为辅助索引,address 为唯一索引. CREATE TABLE `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` int(11) NOT NULL, `address` int(11) NOT NULL, P

随机推荐