阿里内部分享：我们是如何?深度定制高性能MySQL的

阿里云资深数据库工程师赵建伟在“云栖大会上海峰会”的分享。核心是阿里云的数据库服务和MySQL分支的深度定制实践分享。

阿里巴巴MySQL在全球都是有名的。不仅是因为其性能，还因为其是全世界少数拥有MySQL内核团队的。可以负责任的说，随便跑任何的测试工具来测阿里云的MySQL，就知道我们是领先的。

阿里云的数据库服务已经有几个年头了，整个历程从最开始的MySQL，只要有用户需求或者大家使用上面有习惯的，我们都会以高节奏的频度来发布我们数据库的服务。现在大概平台上有数十万的用户数据库实例，从这个分布情况来看，MySQL仍然是一个用户基础比较广的而且使用深度比较高的，我们在MySQL上面也做了非常多的定制功能来满足大家的需求。

RDS MySQL分支介绍

图1RDS MySQL分支

我们的MySQL分支有一个小海豚的LOGO，是专属于阿里云RDS的，我们今年会推出MySQL 5.7的新功能，小版本通常来说都会有一些功能的添加，随着官方的小版本的发布我们的节奏会紧跟着小版本。我们也是拥抱开源的心态，我们对现有的开源分支会从社区拿红利过来，对于一些用户喜闻乐见的或者是我们觉得非常好的会直接拿过来。同时我们索取了之后也会贡献出来，2015年阿里巴巴和谷歌、Facebook、Twitter四家公司成立了一个WebScaleSQL的分支。

功能扩展

图2功能扩展实例

功能扩展上我们会有一些新的语法，这些语法是在使用的过程当中切身体会到的，或者是我们认为过程当中有一些需求的，图2中标红了一些新添加的，前两个想要达到的效果是：大部分情况下我们更新了一条记录,随后我们就想知道这条记录查询出来是什么样的，我们把它组成一条语句，这样在大规模数据部署的时候，这条语句为集团省下来的数据就已经非常可观了。然后是语句超时和DDL fast fail，这个响应变慢带来的连锁反应或者是让你的应用持续性的不可用，或者是崩盘，，它要解决的就是雪崩效应。

功能增强的部分有两个，隐含主键和并行复制。备库一直跟不上主库，我们想要解决的一是隐含主键，如果用户在创建这张表的时候没有给索引，我们会帮用户创建一个隐含索引，这个隐含索引用户是看不到的，不影响你任何的语法和任何的使用，但是它在备库恢复的时候是可以解决大部分问题的。图2中两幅图是我们最早上线的时候没有应对到的一些问题，很多用户在主库上面高并发压测或者是什么原因导致备库一直跟不上，上几万的实例当中也就零星几个，这几个是额外的问题。

资源管控

图3更丰富的Metrics

表和索引的统计：在服务客户的时候遇到两个极端，有一部分用户建表的时候没有一个索引，另外一部分用户会建很多索引，这是两个极端。没有索引查询的效率不高，每一个都建索引也会浪费。我们可以告诉用户这一段时间之内你的索引没有被SQL使用过你可以放心删除。

线程，SQL使用内存统计：我们现在提供的最小规格的是960兆内存的实例，960兆作为一个数据库服务的服务器来说内存肯定是不够用的，我们会有针对线程和SQL的内存统计，你可以很清晰的从这个里面查询出来然后有的放矢。

SQL使用IO资源统计：这是以当前的SQL一条语句或者其他的语句查询出来，然后使用了多少逻辑图、物理图。

SQL使用临时空间统计：这个可以让大家很清楚对于所有压力来源的SQL的使用资源的统计。

图4更完善的SQL审计

SQL审计是我们提供出来的一个额外的，你所有的SQL都可以把一些慢SQL和各类统计的维度来对你的SQL进行审计。

性能优化

图5Aliyun RDS MySQL vs XXCloud MySQL

几个比较典型的性能优化：

• Redo组提交；

• 还有锁拆分；

• 只读事务优化；

• Muti Redo buffer优化。

从图5中的比较看出，我们现在还是一个绝对领先的地位。我们团队针对每一次的MySQL发布、每一次优化都会去跟同类产品做比对。

数据安全

图6 InnoDB数据文件加密

对于企业来说，数据库的数据是企业的生命线，我们希望在数据库的层面上对现有的数据进行一次加密。如果你使用InnoDB的引擎，我们会对数据文件进行加密，加密算法也是国际标准的加密算法。整个一套加密后，你的数据如果丢失，任何人拿到这一部分必须能够到KMS把密钥明文拿出来，更重要的是要把分支的代码拿到，否则解不出来这些数据。

图7 SQL Firewall保护

我们希望增加一个SQL白名单的配置，比如说图7中一个正常的查询语句过来，如果你在这个白名单里面是可以通过查询的，如果说你伪装的话，这个SQL发出来其实就是想把你的数据拖出来，不在这个白名单里面就会被拒绝掉，这个是在中间层加的一层防护。我们在用户使用的过程中是最大限度的放开给大家使用的，比如说你今天要发布一个新业务，你可以在发布随后的两天把监测功能打开，随后你在第三天的时候把白名单的功能切换成保护模式，如果不在这个白名单的就拒绝访问，这就会应对拖库的场景。

行业解决方案

图8防闪断功能 --游戏场景

游戏最让人讨厌的地方就是从服务器掉线了，闪断的这个情况可以发生在链路层的每一层。现在大部分的游戏公司都已经切换到Proxy这个平台上去应对闪断的问题。

图9 Double Binlog保护 --金融场景

金融行业用户希望数据是零丢失的，而且持续可用，我们就在原来的基础上再增加一个SQL。我们希望备库当中有一个人能够参与，这样的话我们可以保证在现有的情况下应对自然灾害或者这一系列的保证数据是零丢失的，而且持续可用。

图10秒杀优化 --电商场景

秒杀场景在电商行业是经常会遇到的，双十一也会有。其实很简单，秒杀对应到数据库里面想要做的事情就一条，同一款商品在数据库里面会有一条库存量，这是一个很简单的减库存的场景。我们现有的更新的锁的力度最小只能到行，就比如过图10中所示的丁字路口，比较并行的就不要去挤，要去排队。我们唯一能做的就是尽可能的在前面排队，进到队列之后尽可能的快点出去，不要进到后端，因为越到后端开销越大。我们可以把这些语句加上Hint，就是说只要更新到减库存之后你的应用不要再做任何处理，我帮你提交就行了，快进快出。还有InnoDB层的排队，语句返回退化成事务提交，也就是我上一个事务没有提交你就不要进来抢资源了，因为你抢到了也是被堵塞住。

图11海量数据场景压缩---对比

我们推出的TokuDB引擎就是尽可能的帮用户压缩数据，图11是一个物联网的例子，因为物联网的特点就是收集的数据踩点比较多，所以它的数据量比较大，我们这个压缩比是大于5倍的。另外我们也支持column压缩，可以自定义column压缩和text/blob高压缩比。

IO优化有一个统计分析的场景。如果今天老板让你帮他统计一下你们去年、前年的订单有多少，这个统计功能很简单，全表扫描一下就出来了，但是它所带来的问题非常巨大，因为内存有限。如果在业务高峰期使用buffer pool就会被污染掉了。因为你已经知道你的数据块访问之后就不再访问了，因为你只想做一个统计分析，所以这次访问直接淘汰出去，就是不走正常的算法，防止buffer pool被污染掉。然后是IOPS限速，防止个别SQL使IOPS过载。

本系列内容还有如下深度文章，详见云栖社区。

• 互联网+视频会议系统详解

• 阿里互联网架构的6大最佳实践

• 企业应用的云上架构演变

• 阿里企业级分布式应用服务EDAS解密

• 阿里云持续交付实战