起因

昨天,在给一个数据表DDL操作时,InnoDB报了如下错误:

100602 13:48:39 [ERROR] Index uk_usplugin_plugid of test/test_user_plugin_0002 has 2 columns unique inside I[......]

Read more

较之MyISAM的一个很大的优势是,InnoDB会缓存数据块。如果系统中的数据量并不大,或者或者活跃数据量并不大时,InnoDB会将这些数据块全部缓存到Buffer Pool(内存)中,这样可以最大限度的提高提供的响应速度,特别是读取。当用户请求需要查询数据块时,InnoDB会首先在Buffer Pool中查找数据,如果Buffer Pool中没有该数据块时,InnoDB会从磁盘上Load对应的数据块,并通过LRU算法替代当前Buffer Pool的缓存块。

1. Buffer Pool中LRU缺点、细节

这样LRU算法的一个缺点是,如果有某一个查询做了一次全表扫描(例如备份,临时DDL等),都可能会导致整个Buffer Pool中LRU链表中的数据块都被替换了,甚至很多热点数据也会被替换,而这些新进的数据块可能在这一次查询之后就再也不会被读到了。我们也称这种情况为“Buffer Pool被污染”了。

在InnoDB则引入了一些新的机制来避免这种情况。算法仍然是LRU算法,但是加上了中点策略(类似于MyISAM的key buffer中的midpoint strategy)。同时引入了参数innodb_old_blocks_time来控制Buffer Pool不被污染。

LRU链表中的数据分为两部分:Sublist of new和Sublist of old。后者包含访问最近没有访问的数据块(链表越后面的数据块,最近越没有被访问)。默认情况,前者占63%(5/8),后者37%(3/8)。

BufferPoolLRU[......]

Read more

InnoDB Plugin特性介绍-2:快速DDL

2010-04-26 19:11  |  分类:MySQL

InnoDB Plugin在快速DDL上做了一些改进,在做的实验中看到,创建secondary indexes时,大约快了20%。

1. 原理

在MySQL5.0里面,如果数据表的记录数很多,增加和删除索引是非常慢的。CREATE INDEX and DROP INDEX命令是通过先创建一个空的临时表,这个表就是你新增或删除索引后的结构,然后把原表中的全部记录都拷贝(插入)到新的临时表中,最后把原表删除,临时表重命名成原表。

MySQL5.1的一些架构上的改变,可以简化上面的过程(不再需要逐行拷贝数据)。InnoDB Plugin利用这个改变,缩短了大多数情况下的索引变更时间。对InnoDB来说有两类索引:the clustered index and secondary indexes。因为InnoDB的主键是the clustered index,数据存放再此,所以,删除或者添加主键(the clustered index)逐行拷贝也是必须[......]

Read more

Faster Recovery of InnoDB Plugin 1.0.7GA

2010-04-16 17:43  |  分类:MySQL

这两天是O'Reilly MySQL Conference & Expo,期间有很多关于MySQL的相关话题的介绍,包括MySQL、PBXT、Drizzle、MariaDB、XtraDB等等,不过最抢风头的应该是InnoDB1.0.7GA(with MySQL-5.5)的新特性,回头想想,Oracle/InnoDB也酝酿了很久的吧。

无论如何,这些新特性中最吸引我的是InnoDB的Faster Recovery。

一般地,MySQL/InnoDB都是运行在普通的PC Server + Linux(Unix),虽然不期待小型机+AIX的高可用,但想尽一切办法缩短MySQL的不可用时间,仍然是DBA的目标。根据经验,主机OS崩溃、硬件故障,仍然是影响MySQL可用性的最主要因素,当这些故障(OS、硬件)恢复后,另一个非常耗时的恢复就是InnoDB自己的恢复时间。一般主机发生一次重启,正常大约<5分钟,而这时InnoDB恢复可能需要40分钟或者更久(这依赖于Buffer Pool、脏页面比例、TPS等因素)。[......]

Read more

InnoDB Plugin特性介绍-1

2010-04-4 09:21  |  分类:MySQL

迫于开源社区、团体(Google Facebook Percona Xaprb等)的巨大压力,InnoDB Plugin相比Built-in版本有了很大的提升,这些提升多数来自开源社区贡献的代码,虽然本身也有一些改进。

1. 关于Fast locking

在多个线程并发访问相同资源的时候,需要使用一些InnoDB实现的互斥量(mutex)和读写锁(read/write lock)。在Unix-like平台上,InnoDB是通过Pthread的互斥量(这是POSIX标准的一部分)来实现的。在现代OS和硬件平台中,一般都有了更有效的替代方案,多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。
[......]

Read more

InnoDB Plugin新特性:压缩表

2010-03-25 21:28  |  分类:MySQL

Plugin的一个重要的特性就是增加了压缩存储。对于数据中有很多Long column(包括TEXT BLOB或者大VARCHAR)的场景能够大幅节约空间,并提升效率。

1. 谁需要压缩?

在InnoDB中,是以16K的页(Page)为基本的存储单位的。我们知道,InnoDB是的数据是在Clustered index中存储的,在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的,所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩

在InnoDB中,除了B-Tree节点页,还有一类数据页(Page),称为“overflow page”。当需要存储Long column时,如果当前页能够完全存储全部字段时,则存储在当前页中;如果当前页不足以存储全部,则InnoDB选择最长的字段,将其存储到一个单独的页中,我们称这样的页为“overflow page”,而原数据页仅仅需存储一个20Bytes的指针。参考下图:

InnoDB_overflow_page

所以InnoDB除了有上面的B-Tree页外,InnoDB还存储overflow页。事实上,需要压缩的数据页也就是这两类,InnoDB为了获得更好的效率,针对这两类数据页的压缩是使用不同的策略的。

[......]

Read more

Pages: 1 2 Next