在上一篇文章里我们写了如何针对InnoDB清理空闲事务《如何杀掉空闲事务》，在@sleebin9 的提示下，这个功能不仅可以针对InnoDB，也可以用于所有MySQL的事务引擎。

如何在Server层实现呢，sql/sql_parse.cc的do_command()函数是个好函数，连接线程会循环调用do_command()来读取并执行命令，在do_command()函数中，会调用my_net_set_read_timeout(net, thd->variables.net_wait_timeout)来设置线程socket连接超时时间，于是在这里可以下手。
主要代码：

830   /*
 831     This thread will do a blocking read from the client which
 832     will be interrupted when the next command is received from
 833     the client, the connection is closed or "net_wait_timeout"
 834     number of seconds has passed
 835   */
 836   /* Add For Kill Idle Transaction By P.Linux */
 837   if (thd->active_transaction())
 838   {
 839     if (thd->variables.trx_idle_timeout > 0)
 840     {
 841       my_net_set_read_timeout(net, thd->variables.trx_idle_timeout);
 842     } else if (thd->variables.trx_readonly_idle_timeout > 0 && thd->is_readonly_trx)
 843     {
 844       my_net_set_read_timeout(net, thd->variables.trx_readonly_idle_timeout);
 845     } else if (thd->variables.trx_changes_idle_timeout > 0 && !thd->is_readonly_trx)
 846     {
 847       my_net_set_read_timeout(net, thd->variables.trx_changes_idle_timeout);
 848     } else {
 849       my_net_set_read_timeout(net, thd->variables.net_wait_timeout);
 850     }
 851   } else {
 852     my_net_set_read_timeout(net, thd->variables.net_wait_timeout);
 853   }
 854   /* End */

大家看明白了吗？其实这是偷梁换柱，本来在这里是要设置wait_timeout的，先判断线程是不是在事务里，就可以转而实现空闲事务的超时。

trx_idle_timeout 控制所有事务的超时，优先级最高
trx_changes_idle_timeout 控制非只读事务的超时
trx_readonly_idle_timeout 控制只读事务的超时

效果：

root@localhost : (none) 08:39:49> set autocommit = 0 ;
Query OK, 0 rows affected (0.00 sec)
 
root@localhost : (none) 08:39:56> set trx_idle_timeout = 5;
Query OK, 0 rows affected (0.00 sec)
 
root@localhost : (none) 08:40:17> use perf 
Database changed
root@localhost : perf 08:40:19> insert into perf (info ) values('11');
Query OK, 1 row affected (0.00 sec)
 
root@localhost : perf 08:40:26> select * from perf;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    6
Current database: perf
 
+----+------+
| id | info |
+----+------+
|  7 | aaaa |
|  9 | aaaa |
| 11 | aaaa |
+----+------+
3 rows in set (0.00 sec)

完整的patch这里下载：
Note: There is a file embedded within this post, please visit this post to download the file.

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年12月6日 -- Percona对MySQL标准版本的改进 (3)
• 2010年01月14日 -- XtraDB 1.0.6-9编译错误的解决 (0)

原文地址：http://blogs.innodb.com/wp/2009/03/plug-in-for-performance-and-scalability/

Why should you care about the latest “early adopter” release of the InnoDB Plugin, version 1.0.3?   One word: performance! The release introduces these features:
为什么你应该关注最近的InnoDB Plugin 1.0.3版？一个词：性能！这个版本包括了这些特性

• Enhanced concurrency & scalability: the “Google SMP patch” using atomic instructions for mutexing
• 增强的并发可可伸缩性：”Google 多处理机 补丁” 为Mutext锁操作使用原子操作
• More efficient memory allocation: ability to use more scalable platform memory allocator
• 更有效的内存分配：可以使用更多的可扩展内存 分配器（例如tcmalloc）
• Improved out-of-the-box scalability: unlimited concurrent thread execution by default
• 改进的即装即用扩展性：默认无限制的线程并发
• Dynamic tuning: at run-time, enable or disable insert buffering and adaptive hash indexing
• 动态优化调整：在运行时，打开或者关闭插入缓 存和自适应哈希索引

These new performance features can yield up to twice the throughput or more, depending on your workload, platform and other tuning considerations. In another post, we explore some details about these changes, but first, what do these enhancements mean for performance and scalability?
这些新的性能特新可以提升多大两倍甚至更多的的吞吐量，这依赖于你的负载，平台和其他调整事项。在另一篇文章中，我们会探 讨这些改变的一些细节，但首先，我们现探讨这些性能和可扩展性的增强是什么意思，包括哪些内容

In brief, we’ve tested three different workloads (joins, DBT2 OLTP and a modified sysbench) using a memory-resident database. In all cases, the InnoDB Plugin scales significantly better than the built-in InnoDB in MySQL 5.1. And in some cases, the absolute level of performance is dramatically higher too! The charts below illustrate the kinds of performance gains we’ve measured with release 1.0.3 of the InnoDB Plugin. Your mileage may vary, of course. See the InnoDB website for all the details on these tests.
总之，我们已经使用内存驻留数据库（所有数据都载入在内存中）测试了三种不同的工作负载（关联，DBT2 OLTP和修改过的sysbench）。在所有的情况下，InnoDB Plugin的伸缩性明显优于MySQL 5.1内置的InnoDB。在一些场景中，性能提升的水平高的惊人。下面的图说明了InnoDB Plugin 1.0.3的性能提升。你的测试结果可能不同，当然可以在InnoDB网站看到所有测试的细节。

This release of the InnoDB Plugin incorporates a patch made by Ben Handy and Mark Callaghan at Google to improve multi-core scalability by using more efficient synchronization methods (mutexing and rw-locks) to reduce cpu utilization and contention. We’re grateful for this contribution, and you will be too!
这个InnoDB Plugin版本包含了Google的Ben Handy和Mark Callaghan的补丁来提升多处理机扩展性，包括使用了更有效的同步机制（Mutexing和RW-Locks）来减少CPU利用和竞争。我们非常感 谢这个补丁的贡献，相信你也是。

Now to our test results …
现在来看我们的测试结果…

Joins: The following chart shows the performance gains in performing joins, comparing the built-in InnoDB in MySQL (in blue) with the InnoDB Plugin 1.0.3 (in red).
关联：下图展示了执行Join操作时的性能提升，内置InnoDB（蓝）和InnoDB Plugin 1.0.3（红）的比较。

As you can see from the blue bars in the above chart, with MySQL 5.1 using the built-in InnoDB, the total number of joins the system can execute declines as the number of concurrent users increases. In contrast, the InnoDB Plugin slightly improves performance even with one user, and maintains performance as the number of users rises. This performance improvement is due in large part to the use of atomics for mutexing in the InnoDB Plugin.
正如你在上面蓝柱上看到的，MySQL 5.1的内置InnoDB，随着并发数的增加系统的执行速度反而下降了。与此相反，InnoDB Plugin随着并发的提升处理速度甚至略有提高，并且随着用户的增长保持着这种性能。这个性能改善很大程度上是因为对Mutexing使用了原子操作。

Transaction Processing (DBT2): The following chart illustrates a scalability improvement using the OLTP read/write DBT2 benchmark, again comparing the performance of the built-in InnoDB in MySQL with the performance of InnoDB Plugin 1.0.3.
事务处理（DBT2）：下入展示了用DBT2测试OLTP读写性能的提升，再次比较了内置InnoDB和InnoDB Plugin 1.0.3的性能。

Here, the InnoDB Plugin scales better than the built-in InnoDB from 16 to 32 users and produces about 12% more throughput with 64 concurrent users, as other bottlenecks are encountered or system capacity is reached. This improvement is likewise due primarily to the changes in mutexing.
这里，InnoDB Plugin伸缩性在16增加到32线程时表现更好，产生比64线程多大约12%的吞吐量。由于其他性能瓶颈或系统容量达到基线。这个提升依然主要依赖于 Mutexing的改变。

Modified Sysbench: This test uses a version of the well-known sysbench workload, modified to include queries based on a secondary index, as suggested by Mark Callaghan of Google.
修改过的sysbench：这个测试使用了著名的sysbench，修改包括基于非主键索引的查询，由Google的 Mark Callaghan建议。

This time, the InnoDB Plugin shows significantly better scalability from 8 to 64 users than the built-in InnoDB in MySQL, yielding as much as 60% more throughput at 64 users. Like the previous examples, this improvement is largely due to the use of atomics for mutexing.
这次，InnoDB Plugin在8~64线程都展示了明显优于内置InnoDB的可伸缩性。在64并发时多大60%的性能提升！像前一个例子，这个提升依然主要靠 Mutexing的原子性。

Modified Sysbench with tcmalloc: This test uses the same modified sysbench workload, but shows the difference between the built-in InnoDB (which uses the internal InnoDB memory allocator) and the InnoDB Plugin when using a more scalable memory allocator, in this case tcmalloc.
使用tcmalloc的修改过的sysbench：这种测试使用相同的sysbench场景，但是不同于内置InnoDB 的是InnoDB Plugin使用了tcmalloc作为内存分配器。

When the new configuration parameter innodb_use_sys_malloc is set to enable use of the memory allocator tcmalloc, the InnoDB Plugin really shines! Transaction throughput continues to scale, and the actual throughput with 64 users has nearly doubled!
当设置innodb_user_sys_malloc变量为tcmalloc作为内存分配器时，InnoDB Plugin依然是亮点！事务吞吐量继续扩展，在64并发时吞吐量提升接近1倍（相对没有tcmalloc的）。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2011年01月19日 -- MySQL小技巧问答(一) (0)

抽空总结一下自己操作MySQL的一些心得体会，做成MySQL小技巧问答系列，给大家作为一些案例参考，也为我自己做一些记录：

1. 在基于ROW的双Master复制下，如何快速大批量订正？
在A<->B的双Master结构下，假设只有一台提供服务，这是我们常用的架构，需要大批量订正数据，如何做最快？用存储过程一批批提交？这有很多的限制，有时候并不可以把一条或多条SQL拆成几段，怎么办呢？binlog不是很好的工具嘛?! ROW格式的binlog，Slave在应用时是直接使用Handler API，并没有走SQL解析，速度非常快，基本上是IO操作了，那么我们可以在备库上直接执行订正SQL，产生的ROW binlog传到主机，就会很快订正完，基本上都比写存储过程快。

2. ROW格式Replication如何实现不带库名的replicate-do-db？
虽然MySQL有replicate-do-db这个参数，但是在ROW格式的binlog下必须使用”db.table”的方式才能生效，USE对ROW格式是无效的。现在我有一个Instance，只需要复制Master的某几个库，但是是ROW格式，SQL都没有使用db前缀，怎么办？可以这么做，把主库需要的库导出来，不需要的库导出结构即可，在Slave导入这些数据及结构，配置skip-slave-errors=all，这样Master复制过来的binlog，只要发现有库有表结构，就不会报找不到表，就不会阻塞复制，但是UPDATE/DELETE过来没有数据也会被跳过错误，间接的实现了replicate-do-db。

3. 大批量乱序数据导入InnoDB很慢如何解决？
InnoDB因为主键聚集索引的关系，如果没有主键或者主键非序列的情况下，导入会越来越慢，如何快速的迁移数据到InnoDB？借助MyISAM的力量是很靠谱的，先关闭InnoDB的Buffer Pool，把内存空出来，建一张没有任何索引的MyISAM表，然后只管插入吧，concurrent_insert=2，在文件末尾并发插入，速度刚刚的，插入完成后，ALTER TABLE把索引加上，记得还有ENGINE=InnoDB，就把MyISAM转到InnoDB了，这样的速度远比直接往InnoDB里插乱序数据来得快。

4. A<–>B–>C–>D结构切换到A<–>B, C<–>D结构出现Slave_lag一直增常如何避免？
这种情况常见与一个双Master集群分离出一套双Master集群，例如从原集群分离一部分库。过快的切换B–>C到C<–>D容易导致主备出现slave_lag，并且一直增长，原因在于A<–>B集群产生的SQL，随同server_id带到了C–>D这个M-S中，当A,B产生的SQL在C,D还没消化完成就CHANGE MASTER为C<–>D时，会导致这写SQL在C,D之间来回传输，因为C,D都认为这个SQL不是自己产生的，因而不销毁，自己执行后写入binlog，于是Slave_Lag就一直增长。
避免的方法很简单，部分写切到C后，先断开B–>C的复制，等一会，看D上已经没有Slave_Lag了，再CHANGE MASTER为C<–>D，这样A,B传过来的SQL都消化完了。

5. 表中存在很多重复数据时，如何删除这些重复数据最快？
在需要给表中某些字段加唯一索引时，而字段中又存在需要重复清理数据的问题，不少DBA都应该遇到过。一般在处理时总是想在数据库中只保留一条，其他的删除，但是这样的SQL写出来总是效率不高，怎么办？其实可以转换思路，把重复的都选出一条出来，存到一张临时表，然后删除原表中所有存在重复的，再把临时表的数据库全部插入原库，这是比较通用并且高效的做法。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2011年01月27日 -- [译]InnoDB官方博客：InnoDB Plugin的性能和可伸缩性 (0)

翻译自：http://blogs.enterprisedb.com/2010/11/29/mysql-vs-postgresql-part-1-table-organization/
翻译不正确之处请指正。

I’m going to be starting an occasional series of blog postings comparing MySQL’s architecture to PostgreSQL’s architecture. Regular readers of this blog will already be aware that I know PostgreSQL far better than MySQL, having last used MySQL a very long time ago when both products were far less mature than they are today. So, my discussion of how PostgreSQL works will be based on first-hand knowledge, but discussion of how MySQL works will be based on research and – insofar as I’m can make it happen – discussion with people who know it better than I do. (Note: If you’re a person who knows MySQL better than I do and would like to help me avoid making stupid mistakes, drop me an email.)
我将要开始一个比较MySQL和PostgreSQL架构系列的博客。本博客的长期读者都已经知道，我最后一次使用MySQL是在很久很久以前两款产品都远不如今天的时候，所以我认为PostgreSQL远好于MySQL。因此，我讨论PostgreSQL如何工作是基于第一手资料，而对于MySQL则是基于很久以前的情况，看博客的同学有很多比我更了解MySQL。如果你是一个比我更了解MySQL的人，发现了我愚蠢的错误请给我一个邮件。

In writing these posts, I’m going to try to avoid making value judgments about which system is “better”, and instead focus on describing how the architecture differs, and maybe a bit about the advantages of each architecture. I can’t promise that it will be entirely unbiased (after all, I am a PostgreSQL committer, not a MySQL committer!) but I’m going to try to make it as unbiased as I can. Also, bearing in mind what I’ve recently been told by Baron Schwartz and Rob Wultsch, I’m going to focus completely on InnoDB and ignore MyISAM and all other storage engines. Finally, I’m going to focus on architectural differences. People might choose to use PostgreSQL because they hate Oracle, or MySQL because it’s easier to find hosting, or either product because they know it better, and that’s totally legitimate and perhaps worth talking about, but – partly in the interests of harmony among communities that ought to be allies – it’s not what I’m going to talk about here.
写这些文章，我要尽量避免作出哪个系统更好的判断，而是侧重于介绍他们架构的不同，也许是一些各种架构的优势。我不能保证这些观点是完全不带偏见的（毕竟，我是一个PostgreSQL代码的提交者，而不是MySQL的提交者），但是我会尽量做到不偏重某一个。此外，考虑到我最近已经跟Baron Schwartz和Rob Wultsch说的内容，我将完全忽略MyISAM和所有其他存储引擎，而重点关注InnoDB。最后，我将专注于架构的差异。人们有时选择使用PostgreSQL是因为他们恨甲骨文，或者选择MySQL因为它更容易找到托管服务，或其他一些产品因为他们知道它更好，并且这是完全符合授权的。这些但这不是我想要谈的。（译者注：最后一段话太绕口，翻译不了，只翻译大意）

So, all that having been said, what I’d like to talk about in this post is the way that MySQL and PostgreSQL store tables and indexes on disk. In PostgreSQL, table data and index data are stored in completely separate structures. When a new row is inserted, or when an existing row is updated, the new row is stored in any convenient place in the table. In the case of an update, we try to store the new row on the same page as the old row if there’s room; if there isn’t room or if it’s an insert, we pick a page that has adequate free space and use that, or failing all else extend the table by one page and add the new row there. Once the table row is added, we cycle through all the indexes defined for the table and add an index entry to each one pointing at the physical position of the table row. One index may happen to be the primary key, but that’s a fairly nominal distinction – all indexes are basically the same.
因此，我将说的内容是，MySQL和PostgreSQL的表和索引存储在磁盘上的方式。在 PostgreSQL，表数据和索引数据是完全分开存储的。当新行插入，或现有的行被更新，新行是表中的任何方便保存的地方保存。在更新的场景下，我们尝试在页内还有空间的情况下存储新行与旧行在同一个页上。如果没有空间，或者如果它是一个插入操作，我们将选择一个有足够空闲空间的页，使用它，或者扩展一个新页把新行放入。我们轮训表上定义的所有索引，并添加一个索引项指针指向表中新行的物理位置。这个索引也许是主键，也许是一般的索引，但是所有的所有索引都是基于一样的操作。

Under MySQL’s InnoDB, the table data and the primary key index are stored in the same data structure. As I understand it, this is what Oracle calls an index-organized table. Any additional (”secondary”) indexes refer to the primary key value of the tuple to which they point, not the physical position, which can change as leaf pages in the primary key index are split. Since this architecture requires every table to have a primary key, an internal row ID field is used as the primary key if no explicit primary key is specified.
在InnoDB中，表数据和主键索引是存在同样的数据结构中（译者注：主键聚集索引）。据我的理解，这就像Oracle的索引组织表（译者注：还是有一些区别，索引组织表完全按索引排序，但是InnoDB只按主键排序）。任何非主键索引指向主键索引的位置，而不是物理位置，所以主键索引页的页节点分裂不会导致数据改变。由于这种架构要求每个表都有一个主键，所以如果没有定义主键内部将隐含定义一个主键（译者注，内部定义的主键为6字节）。

Since Oracle supports both options, they are probably both useful. An index-organized table seems particularly likely to be useful when most lookups are by primary key, and most of the data in each row is part of the primary key anyway, either because the primary key columns are long compared with the remaining columns, or because the rows, overall, are short. Storing the whole row in the index avoids storing the same data twice (once in the index and once in the table), and the gain will be larger when the primary key is a substantial percentage of the total data. Furthermore, in this situation, the index page still holds as many, or almost as many, keys as it would if only a pointer were stored in lieu of the whole row, so one fewer random I/Os will be needed to access a given row.
由于Oracle支持两种选择（索引组织表和堆表），他们可能都非常有用。一个索引组织表似乎在多数SQL是通过主键查找，以及每行的大部分数据是主键的一部分的时候非常有用。要么因为主键列比其余的列长，或因为行总体而言是比较短的。存储整行数据在索引上避免了同样的数据存两分（一份在索引，一份在表中），但是如果主键占数据行的比例较大时，数据增益（译者注：数据+表的重复数据量）将更大。此外，在这种情况下，索引页将保存很多或几乎一样多的数据，访问数据时在索引页中就可能得到整行需要的列，所以这可以减少随机IO（译者注：覆盖索引扫描，Index Scan）。

When accessing an index-organized table via a secondary index, it may be necessary to traverse both the B-tree in the secondary-index, and the B-tree in the primary index. As a result, queries involving secondary indexes might be slower. However, since MySQL has index-only scans ( PostgreSQL does not ), it can sometimes avoid traversing the secondary index. So in MySQL, adding additional columns to an index might very well make it run faster, if it causes the index to function as a covering index for the query being executed. But in PostgreSQL, we frequently find ourselves telling users to pare down the columns in the index to the minimum set that is absolutely necessary, often resulting in dramatic performance gains. This is an interesting example of how the tuning that is right for one database may be completely wrong for another database.
当通过非主键索引访问一个索引组织表，可能需要遍历非主键索引的B树和主键索引的B树。因此，查询涉及非主键索引可能会变慢。然而，由于MySQL有Index-Scan方式（译者注：访问索引即可获得数据） 而PostgreSQL没有，它有时访问非主键索引就能拿到数据。因此，在MySQL中，添加额外的列索引如果带来覆盖索引的查询计划，则很可能使SQL运行得更快（译者注：这个不完全对，索引多的话索引页分裂时的物理IO操作还是比较多的，推荐满足需求的情况下减少索引，除非你能保证覆盖索引经常被用到）。但是在PostgreSQL里，我们经常发现自己告诉用户减少索引到满足要求的最低限度时往往能带来巨大的性能提升。这是一个有趣的例子，如何调整数据库在不同的数据库中是完全相反的方法。

I’ve recently learned that neither InnoDB nor PostgreSQL supports traversing an index in physical order, only in key order. For InnoDB, this means that ALL scans are performed in key order, since the table itself is, in essence, also an index. As I understand it, this can make a large sequential scan quite slow, by defeating the operating system’s prefetch logic. In PostgreSQL, however, because tables are not index-organized, sequential scans are always performed in physical order, and don’t require looking at the indexes at all; this also means we can skip any I/O or CPU cost associated with examining non-leaf index pages. Traversing in physical order is apparently difficult from a locking perspective, although it must be possible, because Oracle supports it. It would be very useful to see this support in MySQL, and once PostgreSQL has index-only scans, it would be a useful improvement for PostgreSQL, too.
我最近获悉，PostgreSQL跟InnoDB一样也支持通过主键索引顺序遍历（译者注：InnoDB访问全表返回数据按主键顺序排列）。对于 InnoDB，这意味着所有的全表扫描是在扫描主键索引，主键索引本身就是表。据我了解，这可能导致大的顺序扫描慢很多（译者注：这个比较扯淡，在数据静止的情况下，PostgreSQL一样要通过block的指针访问下一个block，InnoDB通过页的指针访问下一个页）。在PostgreSQL，因为表不是按（主键）索引组织，顺序扫描总是按物理顺序进行，并且完全不需要访问索引，这也意味着我们可以跳过任何访问索引非叶子节点的IO或CPU开销（译者注：这位兄台应该忘记了什么是B+树）。显然按物理顺序访问是很困难的，但是肯定可以实现，因为Oracle支持。这是MySQL一个非常有用的功能，PostgreSQL一旦有了覆盖索引扫描功能，对PostgreSQL也将是非常有用的提升。

One final difficulty with an index-organized table is that you can’t add, drop, or change the primary key definition without a full-table rewrite. In PostgreSQL, on the other hand, this can be done – even while allow concurrent read and write activity. This is a fairly nominal advantage for most use cases since the primary key of a table rarely changes – I think it’s happened to me only once or twice in the last ten years – but it is useful when it does comes up.
使用索引组织表的最后一个问题是不能在不重建全表的情况下添加，删除或变更主键索引定义。反而在PostgreSQL里，这是可以做到的——即使当允许并发读写活动时。在大多数情况下（InnoDB）具有优势，因为在大多数场景下一旦定义主键不太可能更改 。在我最近十年内这只碰到一次或两次——但是它真的发生时，（PostgreSQL）还是很有用的。

I hope that the above is a fair and accurate summary of the topic, but I’m sure I’ve missed a few things and covered others incompletely or in less detail than might be helpful. Please feel free to respond with a comment below or a blog post of your own if I’ve missed something.
我希望以上是这个专题比较公正和准确的总结，但我敢肯定，我已经错过了一些东西，或者覆盖一些内容不完全，缺少一些可能会有所帮助的细节。请随时反馈在下面的评论中评论您对我遗漏的一些内容的看法。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2011年01月27日 -- [译]InnoDB官方博客：InnoDB Plugin的性能和可伸缩性 (0)

InnoDB的主要IO操作都是在Master Thread（srv0srv.c）中完成的，所以分析InnoDB的IO调度，就一定要分析Master Thread线程。

下面是我画的一张流程图，标识了整个Master Thread的调度流程。红色部分是InnoDB Plugin/XtraDB对原有InnoDB引擎的改进。
每个Process文字中最下面的括号是进行这个操作的具体函数，可以参照源代码阅读本图。

顺便解释一下“插入缓冲”（Insert Buffer）：InnoDB为了避免更新数据时更新索引损失太多性能，使用了这种称为Insert Buffer的方法来缓冲索引更新，对于非聚集索引（主键索引）、唯一索引的修改，不是每次都直接插入索引页，而是先判断要更新的这一页在不在内存中，如果不在则存入Insert Buffer，按照Master Thread的调度规则来合并非唯一索引和索引页中的叶子结点，这样经常能减少更新索引的代价。为什么要求是非唯一索引（排除主键索引和唯一索引）呢？因为唯一索引要检查记录是不是存在，所以必须把修改的记录影响的索引页读出来才知道是不是唯一，这样Insert Buffer就没意义了，反正要读出来，所以只对非唯一索引有效。
show innodb status中的“INSERT BUFFER AND ADAPITIVE HASH INDEX”里面显示了Insert Buffer的效果。

更正一部分，发现在刷新100个赃页后，InnoDB认为刷新耗时已经超过一秒了，无需等待，设置skip_sleep=TRUE，直接跳过os_pthread_sleep，进行下一次判断。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2010年12月6日 -- Percona对MySQL标准版本的改进 (3)

周末有空读了下Percona XtraDB对MySQL InnoDB的改进点，这里给大家分享下。

一、对可扩展性的改进：
1. 提升Buffer Pool的扩展性
InnoDB Buffer Pool一个众所周知的问题是大并发查询执行的争用，XtraDB将Buffer Pool的全局Mutex拆成了多个Mutex以减少争用。

2. 提高InnoDB IO扩展性
XtraDB增加了许多变量去调整IO到最佳状态，包括调整checkpoint、后台读写数据文件线程数等等的参数。

3. 多个回滚段
为提供一直读，InnoDB将事务修改的数据写到回滚段。回滚段被一个独立的Mutex保护，这直接导致了写密集型的工作并发不高。在 XtraDB可以改变回滚段的数目（innodb_extra_rsegments），在写密集型操作中可以大幅度提高性能。

4. 可以更高的并发数
InnoDB在回滚段只提供了1024个回滚槽（春哥就遇到过这个瓶颈），如果回滚槽用完，新的事务将不能开始，直到有回滚槽被释放。

二、性能上的提升
1. 专用的Purge线程
在InnoDB一个事务修改的数据被写到共享表空间的undo space，所以InnoDB能提供读一致。到一个事务结束了，undo space的相应区域被释放。但是如果有很多事务，Purge线程清理空间不够快，共享表空间将急剧增长（BRMMS共享表空间巨大应该是这个原因）。这 将导致性能严重下降，甚至可能用完所有的磁盘空间。XtraDB使用了一个专用的线程来清理undo space，这对undo space的清理速度可以提升很多。尽管这可能使整体的性能降低，但是可以大大提高稳定性，因而整体性能略微降低是值得的。

2. 可配置的Doublewrite缓冲
InnoDB使用了double write功能来防止数据损坏，double write的意思是，是写数据到文件前，先顺序写到到共享表空间。如果遇到一个损坏的写，InnoDB将使用这个buffer去恢复数据。尽管数据被写了 两次但对性能影响通常较小，但是在一些高负载环境，doublewrite就成了瓶颈。XtraDB提供了一个选项将doublewrite buffer放在一个独立的磁盘来提升并发性能。

3. Query Cache增强
Percona提供了额外的参数来配置Query Cache，例如忽略SQL中的注释性语句来检查是否可以命中。

4. Fast InnoDB Checksum
InnoDB可以checksum所有从磁盘上读取的页，以提供防止数据损坏的额外安全保障。在XtraDB中，Percona改进算了 checksum算法，可以提供更好的性能。

5. 删除过多的函数调用
当MySQL从socket读数据时，将产生很多fcntl（针对描述符提供控制的函数）调用，导致并发性能下降。Percona移出了多于 的调用。

6. 减少了Buffer Pool Mutex竞争
在InnoDB内核操作时减少了Buffer Pool之间的Mutex争用（拆分Mutex变量）

三、灵活性改进
1. 支持多种页大小
尽管InnoDB支持多种页大小，但是默认的页大小16K无法在不重新编译的情况下改变。XtraDB提供一个系统变量 （innodb_page_size）来改变这个值。更小的页大小可以提升大多数OLTP系统的工作性能，更大的页通常可以提供更好的 OLAP性能。

2. 禁止Replication警告
默认的基于Statement的复制，例如NOW(),RAND()，call存储过程/函数等一些语句，或者UPDATE没有ORDER BY而使用LIMIT，可能是不安全的。在这种情况下，MySQL会发出1592警告（声明语句在Statement日志下是不安全的）。不 幸的是，MySQL 5.1的一个Bug导致Server发出这个警告在一些安全的情况下。索然他不会导致任何与复制相关的问题，但是这会导致Error Log里面存在没必要的报警。这个改进可以避免这些警告。

3. 处理BLOB中的行结束符
Percona(5.1.x-12.x开始，5.1.x-11.x不支持)为MySQL客户端提供一个新的选项（no-remove- eol-carret）来处理Blob字段含\r字符的情况。

4. 复制停止恢复
当使用sql_slave_skip_counter参数时，如果一个事件组的中间某条出错了，slave将跳过所有剩余的时间操作直到这个 事件组结束。表述比较困难，直接看Percona给的使用例子就明白了。
http://www.percona.com/docs/wiki/percona-server:features:replication_skip_single_statement

5. 可固定的预读区
在InnoDB中，预读（read-ahead区域）的大小是动态计算的，但是它经常是一个同样的值。XtraDB(5.1.x-12.x开 始，5.1.x-11.x不支持)可以让这个这个区域的大小固定，避免无用的计算。
这是Facebook放出的补丁：http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/5.1/revision/3538

四、可靠性的改进
1. Crash后同步日志
在InnoDB中，slave复制状态存储在两个不同步的文件中(relay.index和relay.info)。如果slave因为错误 状态而停止，文件将不同步，最后的事务将重新执行。Percona在XtraDB事务日志中增加了复制状态：当重启事务时，slave可以使 用这个信息来实现一致性。
来自Google的补丁：http://code.google.com/p/google-mysql-tools/wiki/TransactionalReplication
这个缺陷可能导致的Bug：http://bugs.mysql.com/bug.php?id=34058

2. Too Many Connections的警告
Percona将“Too Many Connections”这个警告写入Server端的error_log，而不只是客户端报这个错。

3. 错误代码的兼容性
Percona(5.1.x-12.x开始，5.1.x-11.x不支持)提供与MySQL 5.5错误代码的兼容性，避免因为升级到5.5而带来错误码不一样的问题。

4. 文件句柄损坏的表（InnoDB）
MySQL在InnoDB有表损坏之后，所有的InnoDB表都不可用。XtraDB改进了这一点，只是disable损坏的表，数据库依然 可以使用其他的表，损坏的表被锁定。

五、可管理性的提升
1. Fast InnoDB Recovery
InnoDB一直以来有个很麻烦的事情，在crash后回复InnoDB的表非常的缓慢。Percona/XtraDB因为是基于 InnoDB Plugin 1.0.8+的，也具备InnoDB Plugin快速恢复的功能。（早期的Percona版本也能看到XtraDB恢复速度比InnoDB快很多，因为XtraDB早期使用了自己开发的 Fast Revcovery）
一些测试：http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/

2. InnoDB 数据字段大小限制
InnoDB在自己的表缓存（Table Cache）中分配存储表定义（Table Definitions）的内存称为数据字典。默认情况下，一旦打开表，字典中表示它的内部对象将一直保存在内存中，直到表被删除或者服务器重启。如果存 在很多表（例如 10万张或更多，Dubbo就有这种情况，logstat库），可能导致消耗巨大的内存有时可能达到G级别。Percona修改了这种策略，可以设置参数 （innodb_dict_size_limit）来限制数据字典的大小，使InnoDB使用LRU算法来限制数据字典大小，而不是一直存在 内存中，避免因为表太多而内存耗尽。

3. 展开表导入
InnoDB不像MyISAM那样可以在服务器之间拷贝单表定义文件。如果配合Xtrabackup导出，一张表可以在另一个XtraDB导 入。

4. Buffer Pool使用共享内存
当Buffer Pool非常大时，重启后Warn up需要大量磁盘读写，这会消耗很多时间。通过将Buffer Pool存储在Shared Memory中，这些非是耗时的IO将会节省掉。主机重启就没办法了，得用下面的功能。

5. 导出/恢复Buffer Pool
对于使用了很大Buffer Pool的InnoDB，重启数据库很痛苦。通常需要InnoDB Buffer Pool先Warn Up再提供服务，这可能需要很久。XtraDB(5.1.x-12.x开始，5.1.x-11.x不支持)提供了命令可以把Buffer Pool的内容导入或导出，从而可以提高重启提供服务的速度。
使用方法：http://www.percona.com/docs/wiki/percona-server:features:innodb_lru_dump_restore?redirect=1

6. Fast Index Creation
快速索引创建是InnoDB Plugin的功能，只要不是主键变动，修改索引的速度比之前快很多。但是在一些场景下，这可能导致损坏。XtraDB提供参数 （innodb_fast_index_creation）来选择Fast Index Creation功能是否启用，如果关闭，则使用原来的创建方法。

7. Fast Index Renaming
XtraDB（(5.1.x-12.x开始，5.1.x-11.x不支持)）扩展了ALTER TABLE命令，提供在线重命名索引功能，这样不会导致重建索引。（这对我们调整不规范索引名称非常有用）

8. 防止缓存Flashcache
Flashcache通过在SSD上缓存数据来提升性能。它工作时应该让更热的数据缓存才能能提高更好的性能，XtraDB提供了注释提示来 忽略不必缓存的数据。

六、诊断问题方面的提升
1. 额外的INFORMATION_SCHEMA表
Percona/XtraDB提供额外的INFORMATION_SCHEMA表以获得数据库内部更详尽的信息，例如内部缓冲池的内容或统计 信息。

2. 慢查日志扩展
Percona提供了额外的统计数据，可以通过参数启用。它可以帮助我们捕捉需要的事件尽可能详细的信息，简化了慢查分析的难度。

3. InnoDB状态显示
XtraDB整理了InnoDB Status的显示量，提供更好的可读性，状态由24个上升到48个，并且打印了被内部哈希表使用的内存量。通过新的参数可以配置的输出。

4. 计算InnoDB死锁数
当运行一饿事务性的应用程序，总会不同程度的出现死锁，只要不经常出现这并不是大的问题。InnoDB中Show InnoDB Status命令只给出了最后一次死锁额信息，当我们需要知道总的死锁数或一个单位时间的死锁量这里并不能给出。XtraDB增加了一个保存死锁量的状态 变量，通过这个变量可以更好的了解我们数据库上发生的死锁。

5. 可以记录所有Server端命令（syslog）
Percona可以在syslog中记录所有运行在Server端的命令。

6. 响应时间分布
Percona提供了一份报告表明在一定间隔内在服务器上执行Query数。这个信息可以用于监控数据库性能是否稳定。

7. Show Storage Engines
Percona改变了Show Storage Egnines的输出，以表名XtraDB是不是启用。（以前XtraDB也使用InnoDB的名称输出）

8. Query Cache Mutex状态
Query Cache可能导致一些很难被检测出来的问题，Percona修改了show processlist命令，可以输出“Waiting on query cache mutex”状态。

9. 显示锁名称
“show mutex status”命令可以显示当前发生的锁定名称和os_wait值。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2010年01月14日 -- XtraDB 1.0.6-9编译错误的解决 (0)

本文配图来自《高性能MySQL(第二版)》。

在数据库中，对性能影响最大的几个策略包括数据库的锁策略、缓存策略、索引策略、存储策略、执行计划优化策略。
索引策略决定数据库快速定位数据的效率，存储策略决定数据持久化的效率。
MySQL中两大主要存储引擎MyISAM和InnoDB采用了不同的索引和存储策略，本文将分析它们的异同和性能。

MySQL主要提供2种方式的索引：B-Tree（包括B+Tree）索引，Hash索引。
B树索引具有范围查找和前缀查找的能力，对于N节点的B树，检索一条记录的复杂度为O(LogN)。
哈希索引只能做等于查找，但是无论多大的Hash表，查找复杂度都是O(1)。
显然，如果值的差异性大，并且以等于查找为主，Hash索引是更高效的选择，它有O(1)的查找复杂度。如果值的差异性相对较差，并且以范围查找为主，B树是更好的选择，它支持范围查找。

Hash索引各种引擎大同小异，没有太多可探讨性，本文主要讨论不同形式的B树索引。

B树属于二叉平衡树，平衡树就是任何一个节点的左右节点高度差距不能超过1的树，这才是绝对平衡的树。
平衡树比较好的算法是AVL，它通过左旋、右旋及其组合的操作可以保证树绝对平衡。
下面是AVL算法中的全部旋转操作：

平衡树处在任何一个左边的不平衡状态都可以通过相应的旋转操作转移到右边的平衡状态。

数据库采用的B树只在叶子节点记录信息，非叶子节点记录的是范围信息，这是与一般搜索树不同的地方（一般搜索树非叶子节点也记录信息）。
这是一个B+树的结构，InnoDB的索引都采取了这种形式，它在B-树的基础上为每个叶子节点加了一个指针指向下一个叶子节点，这样可以快速的进行范围查找。
MyISAM是否也是B+树我还不能确定，但是B-树我没有想到可以快速进行范围查找的方法，应该也是B+树。

例如这个B+树的例子：

如果我要查找名字以A开头的全部信息，我只要获取第一个叶子节点，然后顺序沿着指向下一个叶子的指针，直到发现当年叶子节点已经不是以A开头则中止，这样只要搜索到第一个叶子节点(O(LogN))再沿着指针检索(O(N))，就可以获取全部索引，如果N个节点的表扫描M个连续值，就是O(LogN)+O(M)，如果B-树则需要回溯到上层节点，这样最差的效率是O(LogN)*M。

对于InnoDB，使用了一种改进的B+树索引，称为聚集索引（Clustered Index），它的不同之处在于索引上不仅有索引值的信息，还有整个索引值所在行的信息，免去了一次通过索引值上的位置去取整行的操作。

假设我们有个表有(col1,col2)列，col1是主键，col2也建立索引。那么在MyISAM引擎中，文件会被这样记录，因为MyISAM是按插入顺序把数据写入文件。如果有删除则空出位置，再次插入如果可以放下则会填充空白，对于不定长的行，存储引擎都会在分页中预留位置，以供更新更长的值（一般是VARCHAR），放不下则会添加到文件结尾，并从原位置删除。所以有时候会有空间浪费，需要Optimize Table来优化。
因此：定长的行比不定长的行效率高！把定长数据和不定长数据分开存储，很多时候可以提高效率。

再来看MyISAM的主键索引，索引Key是主键值，索引Value是行的文件位置，通过这个位置可以直接读取行。从这个图上来看，MyISAM也是采用B+树。

MyISAM的非主键索引，跟逐渐索引没有不同，也是索引行的文件位置。

再看InnoDB的主键索引，索引Key是主键值，索引Value是整行的数据。

InnoDB的非主键索引，索引Key是列值，索引Value是主键值。

对比MyISAM和InnoDB的索引策略：

可以发现MyISAM所有列的索引都是一样，索引Key是列值，索引Value是行的文件位置。
InnoDB的主键索引包含了行的全部信息，索引Key是主键值，索引Value是整行的值。而非主键索引索引Key是列值，索引Value是主键值，取数据时到主键索引中取。

并且在InnoDB中，一个聚集索引是必须的，如果没有定义主键，InnoDB也会自己隐含的建立一个聚集索引作为主键，因为InnoDB的主键索引还有个重要的功能就是行锁，这在我的另一篇文章中分析过。

再来看看我们插入值时会发生什么：

InnoDB会按主键索引顺序组织文件，如果按主键顺序插入，可以直接在最尾部加入。并且只填充页面的15/16，这样可以预留部分空间以供行修改，这样组织的数据是非常紧凑的。

如果主键不是顺序的，我们来看看会发生什么，因为要按主键顺序存放，数据会被不断地移动，调整页面。

所以：InnoDB引擎按主键顺序插入记录是非常必要的，否则性能将会面临很大风险。

类似的文章

• 2009年09月30日 -- MySQL参数调优 (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)

感谢Fenng的提醒，已删除锁粒度和死锁的关系，专门撰文写了锁的粒度与死锁的关系。

InnoDB与MyISAM不同，它实现的是一个行级锁，而非MyISAM的表锁。锁的粒度越大，则发生死锁的概率越小、锁机制开销越小，但并发能力会越低。如果锁的粒度变细，则发生死锁的概率也会增大，锁机制的开销会更大，但是并发能力能提高。表锁是如何实现的呢，以MyISAM为例，是在每个表的结构中加入一个互斥变量记录锁状态，像：
struct Table {
Row rows[MAXROWS];
pthread_mutex_t lock;//表锁
};
这样做的好处就是锁非常简单，当操作表的时候，直接锁住整个表就行，锁机制的开销非常小。但是问题也很明显，并发量上不去，因为无论多小的操作，都必须锁整个表，这可能带来其他操作的阻塞。
行锁又是如何实现的呢，Oracle是直接在每个行的block上做标记，而InnoDB则是靠索引来做。InnoDB的主键索引跟一般的索引不太一样，Key后面还跟上了整行的数据，互斥变量也是加载主键索引上的，像
struct PK_Idx {
Row row;
pthread_mutex_t lock;//行锁
};
multimap pk_idx;
这样的形式。
这样做的好处是锁的粒度小，只锁住需要的数据不被更改，但是问题也很明显，锁的开销很大，每个主键索引上都要加上一个标记，因为锁的粒度很小，可能两个不同的操作各锁住一部分行等待对方释放形成死锁，不过这个是有办法解决的，把上锁的操作封装成原子操作就行，不过并发量会受些影响。

下面是类似InnoDB的Next-Key locking算法的演示:
编译需要加-lpthread参数，例如g++ inno.cpp -lpthread -o inno

#include <iostream>
#include <cstdio>
#include <cstdlib>
#include <string>
#include <map>
#include <unistd.h>
#include <time.h>
#include <pthread.h>
#include <windows.h>
 
#define LOCK pthread_mutex_lock(&lock)
#define UNLOCK pthread_mutex_unlock(&lock)
#define PRINT(STR, ...) LOCK;fprintf(stderr, STR,  __VA_ARGS__);UNLOCK
 
#define MAXROWS 100
 
using namespace std;
 
/* 行结构 */
struct Row {
    int     num;
    string  info;
};
 
/* 主键索引结构 */
struct PK_Idx {
    Row     row;
    pthread_mutex_t lock;//行锁
};
 
/* 表结构 */
struct Table {
    multimap<int, PK_Idx> pk_idx;
    multimap<int, int>      num_idx;
    multimap<string, int>   info_idx;
    Row     rows[MAXROWS];
    pthread_mutex_t lock;//表锁
};
 
Table table;
int pid;
//全局锁
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
/* 随机字符 */
char randChar() {
    return rand()%26+'A';
}
 
/* 随机字符串 */
void randString(string &col, int len) {
    col = "";
    for(int i=0; i<len; ++i) {
        col += randChar();
    }
}
 
/* 初始化数据 */
void init() {
    pid = 0;
    PK_Idx pk;
 
    srand((unsigned)time(0));
 
    //初始化表数据
    for(int i=0; i<MAXROWS; ++i) {
        pk.row.num = rand()%MAXROWS;
        randString(pk.row.info, rand()%10+1);
        //初始化行锁
        pk.lock = PTHREAD_MUTEX_INITIALIZER;
        //写入表数据
        table.rows[i].num = pk.row.num;
        table.rows[i].info = pk.row.info;
        //写入索引
        table.pk_idx.insert(pair<int, PK_Idx>(i, pk));
        table.num_idx.insert(pair<int, int>(pk.row.num, i));
        table.info_idx.insert(pair<string, int>(pk.row.info, i));
    }
    //初始化表锁
    table.lock = PTHREAD_MUTEX_INITIALIZER;
}
 
/*获取范围数据*/
void select_num(int begin, int end) {
    int id;
    int cur_pid;
    multimap<int,int>::iterator it, itlow, itup;
    PK_Idx *pk;
    /* 按字段范围查找ID */
    itlow = table.num_idx.lower_bound (begin);
    itup = table.num_idx.upper_bound (end);
 
    LOCK;
    cur_pid = pid++;
    UNLOCK;
    PRINT("%d : * Start Select:%d,%d *\n", cur_pid, begin, end);
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);//根据ID去查主键索引
        pthread_mutex_lock(&(pk->lock));//在主键索引上加锁
        PRINT("%d : LOCK Row %d: %d\t%s\n", cur_pid, id, pk->row.num, pk->row.info.c_str());
        Sleep(500);
    }
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        PRINT("%d : UNLOCK Row %d\n", cur_pid, id);
        pthread_mutex_unlock(&(pk->lock));//使用完毕依次释放锁
    }
    PRINT("%d : * Select Finished! *\n", cur_pid);
}
 
/*修改范围数据*/
void update_num(int begin, int end) {
    int id;
    int cur_pid;
    multimap<int,int>::iterator it, itlow, itup;
    PK_Idx *pk;
 
    itlow = table.num_idx.lower_bound (begin);
    itup = table.num_idx.upper_bound (end);
 
    LOCK;
    cur_pid = pid++;
    UNLOCK;
    PRINT("%d : * Start Update:%d,%d *\n", cur_pid, begin, end);
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        pthread_mutex_lock(&(pk->lock));
        PRINT("%d : LOCK Row %d: %d\t%s\n", cur_pid, id, pk->row.num, pk->row.info.c_str());
        Sleep(500);
    }
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        PRINT("%d : UNLOCK Row %d\n", cur_pid, id);
        pthread_mutex_unlock(&(pk->lock));
    }
    PRINT("%d : * Update Finished! *\n", cur_pid);
}
 
 
void* test_select(void *) {
    int begin, end;
    srand((unsigned)time(0));
    while(1) {
        begin = rand()%(MAXROWS/2);
        end = begin+rand()%(MAXROWS/2);
        select_num(begin, end);
        Sleep(500);
    }
}
 
void* test_update(void *) {
    int begin, end;
    srand((unsigned)time(0));
    while(1) {
        begin = rand()%(MAXROWS/5);
        end = begin+rand()%(MAXROWS/5);
        update_num(begin, end);
        Sleep(500);
    }
}
 
void test() {
    pthread_t id[2];
    if(pthread_create(&id[0], NULL, test_select, NULL) != 0)
    {
        PRINT("%s", "Create Thread Error!\n");
    }
 
    if(pthread_create(&id[1], NULL, test_update, NULL) != 0)
    {
        PRINT("%s", "Create Thread Error!\n");
    }
 
    while(1){
		Sleep(500);
	}
}
 
int main() {
    init();
    test();
    return 0;
}

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2011年01月27日 -- [译]InnoDB官方博客：InnoDB Plugin的性能和可伸缩性 (0)

今天 XtraDB Release 9 发布了，不过，竟然有编译错误，真是个杯具哇，不过还好，不是什么难解决的错误。

我下载的是 MySQL 5.1.42 和 XtraDB 1.0.6-9，把xtradb的解压文件覆盖mysql的storage/innobase，很Happy的去编译，想很快就能完成，结果一个Error让我郁闷了：
handler/i_s.cc: In function ‘int i_s_innodb_admin_command_fill(THD*,
TABLE_LIST*, COND*)’:
handler/i_s.cc:2995: warning: deprecated conversion from string
constant to ‘char*’
handler/i_s.cc:2991: warning: unused variable ‘cs’
handler/i_s.cc: At global scope:
handler/i_s.cc:2984: warning: unused parameter ‘cond’
make[2]: *** [libinnobase_a-i_s.o] Error 1
make[2]: Leaving directory `/home/plx/Downloads/mysql-5.1.42/storage/
innobase’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/plx/Downloads/mysql-5.1.42/storage’
make: *** [all-recursive] Error 1

我还以为我的GCC参数设置错了，去掉参数直接configure，还是一样的错误。
于是怀疑是不是xtradb本来的问题了，用我的GCC参数编译原版，一切正常，肯定就是xtradb的问题。
Google之无结果，百度之也无结果~

只能自己动手丰衣足食了，先到percona-discus讨论组提问，等待回答。
然后仔细看编译错误发现 真正的Error所在：
handler/i_s.cc: In function ‘int i_s_innodb_buffer_pool_pages_index_fill(THD*, TABLE_LIST*, COND*)’:
handler/i_s.cc:801: error: invalid conversion from ‘const char*’ to ‘char*’

查看了这一行代码：
if((p = strchr(index->table_name, ‘/’)))

于是去查看strchr的函数原型，得到：
extern char *strchr(char *s,char c);

那就判定是index->table_name是const char * 导致的。
于是很简单的加上const_cast，801行改为：
if((p = strchr(const_cast(index->table_name), ‘/’)))

再次编译，成功。

然后看到邮件组里XtraDB的开发人员Aleksandr Kuzminsky也回复我了，确认这是个BUG，然后修正方法跟我也差不多。
不过Aleksandr Kuzminsky也说了，这个问题会导致mysql-test无法通过。

这个版本的XtraDB算比较失败了，期待下一个版本。

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)
• 2010年12月6日 -- Percona对MySQL标准版本的改进 (3)

类似的文章

• 2010年03月20日 -- MySQL索引与存储方式对性能的影响 (2)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)