一些常用网站:

http://labs.mysql.com
http://dev.mysql.com/downloads/mysql/
http://mysqlserverteam.com/

本文根据高效运维系列微信群「运维讲坛」的嘉宾分享整理而成。“高效运维”公众号作为本系列群的官方唯一公众号，原创并独家首发。「运维讲坛」邀请国内运维领域优秀技术专家作为分享嘉宾，其中线上分享每周一次，线下沙龙活动每月一次。

欢迎关注“高效运维”公众号，以免费参加「运维讲坛」每月一次的线下交流活动；并抢先赏阅干货满满的各种原创文章（详情参见文末）。

编 辑

• 闫丽慧@SAP（内容收集&文章整理）

• 董 伟、萧田国（审核&发布）

讲师介绍

赖铮(Allen,Lai)，现任Oracle InnoDB团队Principle Software Developer，主要负责数据库执行引擎和存储引擎的研发。毕业于华中理工大学，从事数据库内核研发十余年，曾在达梦、Teradata担任高级工程师。

精彩观点先知道

1. 引入事务池，所有事务缺省是只读，直到开始写操作，才成为读写事务；

2. Innodb_buffer_pool_size可动态调整（有多爽？你懂的：）；

3. 新增Memcached插件，适合数据量很小、但访问非常频繁的只读操作；

4. 新增虚拟列和虚拟列索引，新的数据压缩和GIS等功能；

5. 优化临时表机制，以提高复杂查询的性能。

主题简介

InnoDB大家都应该非常熟悉，作为MySQL的存储引擎，而且现在变成缺省的存储引擎，它为MySQL提供了强大的存储支持。

伴随着MySQL从5.6演进到5.7，InnoDB也有了诸多激动人心的新变化。本文主要介绍InnoDB 5.7中性能的提升和新功能。

【福利】点击文末的“阅读原文”，即可下载本次分享的PDF哦。

分享内容

在进入主题内容之前，先请阅读我司的法律声明 :)

本次分享，我将从性能和功能两大方面来给大家介绍：

1. 性能提升

MySQL InnoDB在5.7中对性能做了一些非常重大的优化，不光可以大幅加速数据的访问和存储的速度，还能让大家节省很多日常维护的时间。

1.1 事务操作相关优化

在5.7中，我的老板（大牛），Sunny做了一个很重要的工作，就是对InnoDB的事务（transaction）进行了优化。在这方面他做的第一件事情就是创建事务池（Transaction Pool），这样就能减少很多事务创建和释放的开销：

他做的第二件事情就是优化了事务的生命周期管理。所有事务首先都默认为是只读事务，这样这些事务就不会和其他事务冲突，只有当此事务开始一个写操作时才认为它是一个读写事务：

此外，对事务的优先级也做了一些调整:

接下来我们看看经过这些修改之后，性能有些什么变化。

对于只读事务，我们用sysbench oltp测试，5.7比5.6有超过一倍的性能提升！详见下图：

而对于读写事务，我们也有50%左右的性能提升（如下图），是不是很有诱惑？:)

不过，这只是其中一项性能优化，更精彩的是我们在5.7中对临时表的重大性能优化！

1.2 临时表相关优化

在5.7中，我们将临时表从数据字典中分离出来，这样，临时表就不会跟其他正常表争抢数据字典的锁。同时，我们还将临时表的表空间跟普通表空间区别开来，以减少IO的开销

对于临时表的DML操作，我们只记录Undo日志，不记录Redo日志，因为，临时表不需要在Crash的时候Recovery，但是它需要rollback。这样也减少了大量的日志开销。再给大家看看效果:

上图显示了5.7的临时表create和drop的性能提升，这个应该是重复几万次create和drop所耗费的时间。5.7快到飞起来！

而对临时表插入5M行数据的测试，性能也有一倍以上的提升：

删除操作的开销也减少了75%：

Update 操作，开销减少40%左右：

所以，如果大家在应用中会使用InnoDB的临时表，那这个优化就能带来很大的好处。那么，大家有疑问了，我平时不用临时表，这个对我有啥好处？还真有，请看下图：

刚才谈到的这个优化实际上不光是对InnoDB的临时表有用，还对一种大家平时看不见的表，即优化器用的缓存表也有好处。

之前，MySQL的优化器是用MyISAM来缓存SQL执行的中间结果集的，现在，采用了InnoDB优化后的临时表，大家可以看图，明显快多了！

也就是说，如果查询有join，基本上都要用到这项优化。

介绍完两个最大头的性能优化点，接下来我们浏览一下其他一些也非常重要的性能优化工作.

1.3 其他性能优化

这个是对于缓冲区的优化，可以看到，这个优化最重要的是解决在12核甚至更多核机器上性能问题。

另外，缓冲区刷新到磁盘也可以多线程做了:

得益于前面介绍的只读事务的优化，InnoDB的Memcached 插件也有了性能的飞跃，现在已经可以达到1.1M QPS:

建议大家尝试一下，特别是对数据量很小，但访问非常频繁的只读操作，可以采用InnoDB的Memcached插件。对比效果如下：

最后，讲一下DDL相关优化。

MySQL 5.7有了更快的DDL，这里主要指的是Alter table增加索引之类的操作。原来建索引是读一行插一行，现在是读一批，排序再批量插入。所以，性能有了170%的提升。如此一来，大家增加一个索引就快多了。

接下来，我们来看在5.7中增加了哪些新功能。

2. 新功能介绍

2.1 分区功能

以前，InnoDB内部是没有分区的，大家看到的都是在InnoDB外面做的分区。而现在，InnoDB原生支持了分区。

这样带来的好处是，减少了内存开销。以上图所示一个8k的分区的表为例，当打开十个实例的时候，可以减少90%d 内存开销。

除此之外，5.7提供了对一个单独的分区做import/export操作的支持：

2.2 表空间管理

其实这个不是什么新功能，只是让大家以更为习惯的方式来管理表空间而已。

2.3 缓冲区动态调整

动态调整缓冲区的大小，我想大家肯定会喜欢。

大家再也不用关数据库，改配置文件，再启动数据库来修改缓冲区的大小了，so easy！

2.4 日志管理的新功能

日志管理的新功能是自动截断，这样日志文件就不会再不停的增长了。这个功能我想大家也应该挺喜欢。

2.5 支持更大的数据页

之前我们支持的是4k，8k，16k，现在可以支持32k，64k了。这样一些blob数据就可以直接存在页里，访问起来更快。

2.6 GIS的支持

在5.7中最重要的新功能是对GIS的支持。我们在InnoDB内部实现了基于R-tree的空间索引，这样用户就能很方便的查找地理信息数据了。

比如，查找以我为中心，周围2公里范围内的妹子之类的操作将变得异常迅速，:D

2.7 虚拟列和虚拟列上的索引

5.7中还有一个重要功能是虚拟列和虚拟列上的索引。也就是对于那些可以通过其他列的数据计算出来的列，大家可以创建一个虚拟列，它实际上是不存储数据的，每次读这个列都是临时在InnoDB内部计算出来。

这个功能是客户要求的，但我不知道大家在实际应用中是不是对此有需求。

2.8 新的数据压缩方法

另一个重要的新功能是新的数据压缩方法。基于页IO的压缩，也就是说，数据的压缩和解压发生在页IO的过程中。

我们利用了一些文件系统的Punch Hole(文件打洞）功能来辅助实现这一新功能。

其实现方法这里不在赘述，总之效果就是文件更小，效率更高：

2.9 其他新功能

在其他功能方面，我们还增加了一些对字符集的支持，比如GB18030：

还有更完善的全文索引支持：

对于新存储设备的支持方面，我们在5.7中支持了原子写入，在NVMFS上关掉了DW buffer：

还有一些其他功能就不一一列举了，大家可以稍微浏览一下看看有没有自己感兴趣的，尤其是PFS这块，对于运维来说应该有帮助，可以让DBA更多的了解当前系统的状态。

最后，是一些常用网站:

http://labs.mysql.com
http://dev.mysql.com/downloads/mysql/
http://mysqlserverteam.com/

3. 总结

InnoDB在5.7中在性能和功能方面做了很多工作，非常期待大家的试用和反馈，谢谢大家!

【福利】点击文末的“阅读原文”，即可下载本次分享的PDF哦。

如何一起愉快地发展

这是一个新的时代！每个人都有自己的声音，值得被尊重，并且有机会被尊重。

高效运维系列微信群是国内高端运维圈子、运维行业垂直社交的典范。现有会员800余名，其中运维总监及以上级别会员300多名。

“高效运维”公众号值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

来吧朋友，共襄盛举。

提示：目前高效运维两个微信群均已满员，如您愿意，可添加刘玉强个人微信号 kidult0314 为好友，并申请加入我们聊天群（技术讨论+部分水贴，已有来自1群和2群众多喜欢热闹的朋友）。

重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。