MYSQL中InnoDB特性浅谈

许久没有更新博客,上周末放假把网易大牛姜sir的著作MYSQL技术内幕InnoDB存储引擎又翻阅了一番,对当前工作的InnoDB特性有了一些新的认识,下面谈谈自己的读后感.

1. InnoDB的体系架构由一系列后台线程,内存池和文件组成,这点与其他DB有相似之处. 在内存中划分了一块区域,即缓冲池,用来临时存放用户读写的数据页. InnoDB上对缓冲池读写数据页,刷新到磁盘等操作也使用了CHECKPOINT机制,LRU算法,这点与SQLSERVER,DB2等数据库设计一致,这里不再阐述.需要注意的是MYSQL中指定LRU列表的midpoint控制位置由参数innodb_old_blocks_pct控制,该参数决定了新读取的页会插入到LRU尾部多少的位置.一般为37%.

2. 插入缓冲: 插入缓冲是InnoDB存储引擎开创性的设计,主要为了解决非聚集索引插入或更新操作时,由于非聚集索引离散地访问非聚集索引页,从而导致插入操作性能下降.这是因为非聚集索引本身的特性决定的.所以INNODB引入了插入缓冲这一特性,对于非聚集索引的插入或更新操作,不是每一次直接插入到索引页,而是先判断插入的非聚集索引页是否在缓冲池中,若在则直接插入,如果不在则先放到到一个Insert Buffer对象中.然后再以一定的频率和情况进行Insert Buffer和辅助索引页子节点的合并操作,这时通常能将多个插入合并到一个操作中(因为在一个索引页中),这样大大提高了对于非聚集索引插入的性能.

插入缓冲的使用需要同时满足两个条件:1.索引为辅助索引;2.索引不是唯一的.因为在插入缓冲时,数据库并不去查找索引页来判断插入的记录的唯一性.如果去查找肯定又会有离散读取的情况发生,从而导致insert buffer失去了意义.

插入缓冲目前存在的问题主要是在写密集的情况下,插入缓冲会占用过多的缓冲池内存.

目前DB2,SQLSERVER上均没有插入缓冲这项特性.

3.Double-Write: 两次写主要带给InnoDB数据引擎的是数据页的可靠性.在其他数据库下,当某个数据页在正在写的过程中发生灾难,如电源问题导致宕机,该数据页会出现写失效的情况.当然我们可以通过重做日志进行恢复,但是由于重做日志记录的本身是对页的物理操作,如偏移量,写入记录等等.当物理页本身在宕机过程中损坏,再通过重做日志恢复不可行.面对这种情况,DB2,SQLSERVER通过内部命令REPAIRDB或者其他REPAIR工具去修复数据页.而MYSQL InnoDB两次写特性保证数据再在写入磁盘前先顺序写入共享表空间上,然后通过函数同步磁盘.这样相当于创建了数据页的一个副本.

4.自适应哈希索引:这是MYSQL INNODB另一个重要特性. InnoDB存储引擎会监控对表上各索引页的查询,如果观察到建立哈希索引可以带来速度提升,则自行建立哈希索引.InnoDB存储引起会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引.这个是SQLSERVER和DB2所不具备的

时间: 2024-11-08 07:52:31

MYSQL中InnoDB特性浅谈的相关文章

mysql中innodb和myisam的区别

InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,5.7之后就不一样了 1.事务和外键InnoDB具有事务,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择2.FULLTEXTInnodb不支持全文索

mysql中InnoDB存储引擎的行锁和表锁

Mysql的InnoDB存储引擎支持事务,默认是行锁.因为这个特性,所以数据库支持高并发,但是如果InnoDB更新数据的时候不是行锁,而是表锁的话,那么其并发性会大打折扣,而且也可能导致你的程序出错. 而导致行锁变为表锁的情况之一就是: SQL的更新(update)或者删除(delete)语句中未使用到索引,导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索(表锁).而如果使用了索引的话,InnoDB只会通过索引条件检索数据,而只锁住索引对应的行(行锁). 下面记录一下我遇到

MySQL中innodb引擎分析(初始化)

MySQL的存储引擎是以插件形式工作的,这应该是MySQL的一大特色了吧! 依据<深入理解MySQL>的内容,5.1版本号时存储引擎的插件化都还不是彻底,确切的说是刚加入的特性.为MySQL加入一个存储引擎时,须要更改一些上层代码,零散的更改本来就有点麻烦,同一时候project也要又一次编译一次.我听别人说,已经能够不改C/C++代码就直接加入引擎了.这种话,折腾存储引擎的话就更方便了! 这段代码来自ha_innodb.cc,这是MySQL中申明存储引擎插件的标准过程.这段代码利用了宏.在p

mysql中innodb和myisam对比及索引原理区别(转)

InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,5.7之后就不一样了 1.事务和外键 InnoDB具有事务,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能 MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择 2.全文索引 I

mysql之Innodb特性adaptive hash index

1.Adaptive Hash Indexes 定义 If a table fits almost entirely in main memory, the fastest way to perform queries on it is to use hash indexes. InnoDB has a mechanism that monitors index searches made to the indexes defined for a table. If InnoDB notices

MySQL中InnoDB全文检索

InnoDB存储引擎从1.2.x开始支持全文索引技术,其采用full inverted index的方式.在InnoDB存储引擎中,将(DocumentID,Postition)视为一个ilist.因此在全文检索的表中,有两个列,一个是word字段,一个是ilist字段.并且在word字段上有设索引.此外,由于InnoDB存储引擎在ilist字段上存放了Position信息,故可以进行Proximity Search,而MyISAM不支持该特性 如之前所说,倒排索引需要将word存放在一个表中,

InnoDB MVCC浅谈

作者:周琳//转载请标注出出处 1.行记录隐藏列的意义 可以从row_search_for_mysql(storage/innobase/row/row0sel.cc, line 3661)函数开始,这个函数是mysql服务器层面搜索记录的函数,该函数有一个重要的参数就是row_prebuilt_t* prebuilt,该参数是包含了查询的记录的信息.进行Debug调试可以发现内存中一行记录包含了如下的几个隐藏列: 测试的客户端: 测试实例中,test1表只有id为int的一列. 从gdb信息中

mysql中InnoDB表为什么要建议用自增列做主键

InnoDB引擎表的特点 1.InnoDB引擎表是基于B+树的索引组织表(IOT) 关于B+树 (图片来源于网上) B+ 树的特点: (1)所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的; (2)不可能在非叶子结点命中; (3)非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层; 2.如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引.如果没有显式定义主键,则InnoDB会选择第一个不包含有NU

MySQL中InnoDB脏页刷新机制Checkpoint

我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓冲池页中取数据,那为什么还要刷新脏页到磁盘呢?如果重做日志可以无限增大,同时缓冲池足够大,能够缓存所有数据,那么是不需要将缓冲池中的脏页刷新到磁盘.但是,通常会有以下几个问题: 服务器内存有限,缓冲池不够用,无法缓存全部数据 重做日志无限增大成本要求太高 宕机时如果重做全部日志恢复时间过长 事实上,当数据库