服务了百万用户的腾讯云MySQL内核揭秘

腾讯云数据库国产数据库专题线上技术沙龙已圆满结束，本期带来赖铮分享的《庖丁解牛：腾讯云CDB内核架构及亮点功能解密》直播视频和文字回顾。

关注“腾讯云数据库”公众号，回复“0530赖铮”，即可下载直播分享PPT。

大家下午好。非常高兴今天下午有这个机会和大家做一个分享。首先做一个简单的自我介绍，我叫赖铮，现在是腾讯云CDB/CynosDB内核的架构师，我之前一直都是从事于数据库内核的研发工作，差不多20年。之前在达梦，Teradata和Oracle都工作过。在Oracle的时候是在MySQL InnoDB官方团队，做了一些特性的设计和实现工作，比如说GIS支持，透明数据加密，还有新的数据字典等。到腾讯来了之后，我现在主要担任的是CDB内核研发工作。

我今天要分享的主题是庖丁解牛-CDB内核架构和亮点特性揭秘。为什么叫庖丁解牛呢，庖丁大家都知道，就是厨师。我在数据库领域这一块也相当于一个厨师。而解牛就是我们来分析一下腾讯云CDB的内核，把我们腾讯云CDB内核的各个模块给大家进行详细的介绍，好好的讲一讲它里面的构造，还有我们在每个模块做的一些事情。

开场白就到这里，我们开始进入正题。

今天我会分四个部分来介绍一下CDB的内核。

首先第一部分我会介绍一下CDB内核的一些简单的情况，包括为什么要做它，它的研发历程是什么样，还有包括CDB内核现在的状况是什么样。

第二部分我会讲CDB内核架构，还有它的一些亮点功能。就像我刚才说的一样，我们是基于内核的整体架构，然后分模块来给大家介绍每个模块我们做的一些事情。

第三部分，这个比较有意思的事情是我会讲一下我们CDB内核的质量控制。也就是说我们在做CDB内核的过程之中，我们是怎么样去保证我们CDB内核的质量。这部分讲完之后。

最后一部分是CDB内核的一个最佳实践，我会给大家讲一个我们最近实际线上遇到的一个应用实践，详细给大家介绍一下我们CDB内核团队发现了一些什么样的线上问题，我们又是怎么样去解决掉这些问题的。

接下来我们进入第一个部分，简单介绍一下CDB的内核TXSQL。

有部分同学可能听过我以前的分享介绍过TXSQL。TXSQL是我们腾讯CDB内核团队基于MySQL自研的一款数据库内核产品，它实际上是Tencent  MySQL的缩写，它也是我们腾讯云，以及腾讯内部在使用的主要数据库内核。那为什么会有TXSQL这个数据库内核呢？

首先是因为大家都知道MySQL是世界上，尤其是互联网这个领域用的最多的一款数据库产品。所以基于MySQL来提供腾讯云上面的数据库服务能满足最为广泛的用户需求。为了达到这个目的，我们就要面对各种挑战，比如说海量运营。因为在云上，不管是产生数据的规模还是使用数据的频率都是非常大的，所以我们就需要改进和完善MySQL，提供更丰富的功能和更强大的性能来面对这样一个挑战，为云上的服务提供更强有力的支撑。另外一点，因为大家都知道MySQL是一个开源数据库，我们在做好自己的功能开发后，也会把我们的研发成果回馈到开源社区里面，帮助MySQL开源社区有一个更好的发展。这是简单介绍为什么要有TXSQL。

接下来，我们来看一下整个TXSQL的发展历程。最早我们是从MySQL5.1版本开始做的，最早5.1和5.5，基本上就是一些Bugfix，再加上我们的管控系统OSS需要的一些功能。到了5.6之后，就有一些我们自己研发的内容了，随着我们内核团队的不停壮大，像做了一些给DBA提供支撑的功能，然后还包括读写方面的一些优化，性能方面的优化，当然还包括一些Bugfix。到了5.7，我们做内核的同学更多了，有更多的内容被研发出来。比如说加密，待会我会讲到。比如说审计，还有线程池，诸如此类比较重要的一些企业级功能。

到了现在，腾讯云上面的主力版本就是5.6和5.7，基本上是这两个版本在为腾讯云的客户提供服务。在未来呢，很快，因为我们8.0也会发布，8.0的第一期已经做完了，现在正在紧张的测试，在不久的将来就会公布给大家，让大家来试用。

在8.0版本里面，我们提供了更多我们自研的一些功能，比如说CStore列存引擎，还有我们最后一场嘉宾将会提到的基于AEP新硬件的智能优化。值得一提的是我们内核团队除了在TXSQL这边有持续演进，提供新的产品和新的迭代之外，我们还研发了另外一款数据库内核产品CynosDB，它是在我们TXSQL5.7的基础上衍生出来的一款云原生数据库。

有同学可能上周六听少华同学讲过CynosDB，的主要架构和功能，它是一款存储和计算分离的架构的一个云原生的数据库，它能做到的是可以快速的扩展计算能力或者是存储能力，而且它是基于Redo的复制。所以它不管是性能、功能还是可扩展性都是比单实例版的要强很多。感兴趣的同学可以后续再去了解一下我们CynosDB的一些情况。这就是我们整个TXSQL从最早期的5.1版本到8.0版本的一个演进的过程。

接下来我们看一下我们现网现在的情况。大家目前也应该知道我们是除了阿里云之外的第二大国内的云服务提供商。现网客户分布于各行各业，大家比较熟的比如：电商平台的拼多多、微盟、小红书和蘑菇街，拼多多是我们现在最大的客户。然后金融支付里面有微信支付、康泰人寿这样的一些客户。影音娱乐领域包括bilibili，畅游。还有科技教育这一块像三一重工跟腾讯课堂。因为我们的现网客户来自各行各业，所以我们会面对不同行业，不同场景的各种不同需求。

接下来我就给大家讲一讲我们CDB内核的主要架构，还有它其中一些亮点特性。

首先，这个图是CDB内核的整体架构，最上面是客户端连接进来，它的请求进来之后会到我们线程池，这个情况是线程池开启的情况，线程池如果关闭的情况可能就没有这个线程池这一块了。它请求下来之后到优化器、执行器这一层进行语法解析，然后生成执行计划，由执行器做执行。执行器就会访问到底层存储引擎的数据，存储引擎有InnoDB，还有刚才我提到的CStore，还包括MyISAM，这个是MySQL官方原来的一些引擎。这些数据都是存储在我们的CBS，腾讯云高效云硬盘。

我们这边还提供了一些辅助的插件，比如说为了支持审计而提供的审计插件，为了数据加密提供的数据加密插件。审计插件会把审计的信息发送到审计系统，然后记录下来，并支持进行查询。在加密插件会访问KMS，一个密钥管理系统，去获得密钥，然后从密钥拿回来之后对数据进行加密和解密。还有就是我们的复制，现在我们支持的是基于半同步复制的复制模式。实际上在这个半同步复制插件里边，我们也做了一些优化，比如为了支持金融领域的场景，我们增加了强同步，并且对强同步背景下的性能做了优化。所有这些模块我待会都会一一讲我们做了哪些事情。

接下来我们分模块来讲一讲CDB内核的一些核心功能。

首先就是线程池，就是刚才我们看到最上面这一层的线程池。大家都知道，其实很多数据库产品都提供线程池的功能。在这个解决方案里面，它创建了多个服务线程，这些服务线程会分别的从两个队列里获取客户请求，一个是高优先级队列，一个是低优先级队列。事实上，大家知道，线程池是为了避免在高并发情况下线程频繁切换，资源争抢等问题导致系统的性能急剧下降的问题。

大家看到右边的图，随着并发的不停增加，没有线程池的曲线是往下走的。而有了线程池之后，用户连接，它都是固定数量的后台线程在系统里面运行，来提供服务，这样的话就会减少很多并发产生的压力。大家可以看到图里面，有了线程池的情况下，在连接数上来之后，性能还是能够保持一个比较平滑的曲线，甚至有所上升。

TXSQL在线程池里面还进一步做了优化，比如说在有些低优先级的客户连接请求过来之后，有可能发生的饿死的情况，所以针对这种情况，我们会随着他放在低优先级队列里面时间的增大，相应调高它的优先级，让它也能够有被执行到的机会。

第二个重点功能是安全性方面的审计。TXSQL的审计也是基于官方的一套审计接口实现了一个自己的审计插件。我们的审计有一个后台线程在不停的去获得客户发过来的SQL语句，然后进行按照用户设定的审计规则进行过滤，过滤完之后会把它放到一个审计数据文件里，同时有一个审计代理服务，它会不停的去读取审计数据文件里面的内容，并把它发送到CTSDB这样一个审计日志系统里面存储起来。客户可以通过我们的CTSDB来查询需要的审计记录。

另外一个数据安全性方面的功能是加密。刚才提到了我之前在MySQL官方做了一项叫透明加密的工作，实际上TXSQL加密功能也是基于MySQL官方的透明加密来做的。它集成了KMS和CAM这两个腾讯云上的加密服务组件。KMS就是腾讯云的密钥管理系统。用户设置的密钥，或者是系统自动生成的密钥就会存放在KMS里面。然后TXSQL需要对数据进行加密的时候，会去问KMS要它的密钥，对数据进行加密。当从磁盘上读取数据的时候，会相应的解密，同样也是用KMS里面拿到的密钥进行解密。

实际上MySQL的TDE是有两层密钥，我们KMS里面存的叫master key，第二层密钥叫tablespace key，也就是说每一个IDB文件有一个KEY。这个KEY是被master key加密之后写在IDB文件的头部。通过这样两层KEY的模式就可以避免master key改变后，需要把所有数据全部重新加密的问题。只要把tablespace key重新加密，放到IDB文件的头部就可以了。

接下来是一个之前大家没有太多接触的一个特性，就是TXSQL的列存引擎CStore。CStore列存引擎是为了解决大规模数据的查询性能方面的问题。大家都知道，InnoDB是行存储，所有的字段都是一行一行的存。列存引擎是按列存的，一列的数据存在一起，这样做会带来很多好处，比如查询的时候，一个表里面有20个字段，你可能只需要查其中的两个字段的信息，对于列存引擎，它就不需要去获取另外18个字段的信息，只要去搜索其中两列的数据就可以了。所以它能够避免访问你查询不需要涉及到的列，来减少大量的IO。

另外一个好处是它可以做压缩。因为你按列存的话，因为都是同样的数据，所以可以进行比较高压缩比的压缩，从而减少大量的存储空间。另外还有就是查询优化，因为数据是按列存的，查询的时候可以用各种形式的索引来过滤数据，还可以通过维护数据的统计信息，聚合类查询的预计算这些方法来对整个查询的性能进行极大幅度的优化。我们现在CStore还支持了快速加载，就是用MySQL标准的LOAD语句把大规模的数据LOAD到CStore存储引擎里。通过多核的并行处理，加载速度可以比innoDB快10倍。

执行引擎方面的话，我们支持查询任意多列的组合，单节点可以支持百亿记录的秒级查询。JOIN算法的话，也包括了HASH  JOIN，CStore里面的HASH  JOIN跟8.0里面的HASH  JOIN还是不一样的。大家可以从右边这张架构图上可以看到，实际上CSTORE引擎是有自己的优化器和执行器在里头的，虽然它是通过MySQL的API进行交互，但它底下是有自己的优化器跟执行器。

CStore主要适合应用的场景是大规模的数据分析场景，比如说有一个TB级数据规模的一个实例，可能就需要用CStore这样的引擎来对数据进行处理，并且在这个基础上进行一些分析型复杂查询。还有一个值得一提的是，我们CStore和InnoDB是共存的，也就是说在一个实例里面，CStore和InnoDB一样，也是一个存储引擎，只不过它是一个列式存储引擎，InnoDB是一个行式存储引擎。

我们现在也可以支持跨引擎JOIN。另外要说明一点，CStore现在会放在TXSQL8.0的产品里面推出，到时候8.0出来之后，欢迎大家来试用。

接下来就是我们第四场的嘉宾会详细讲的一个特性，就是在非易失性存储新硬件方面的优化。主要的优化点是通过利用新硬件上提供的PMDK接口来替换掉原来InnoDB的POSIX接口来将日志文件写到非易失性存储的硬件上面。因为大家都知道，非易失性存储的性能是非常高的，它虽然比不上内存，但是比普通的SSD要快很多。所以，我们如果把日志放在新硬件上面，然后通过PMDK的接口去进行存取的话，这个性能就会高很多。

第二个就是线程绑核，我们把使用PMDK接口的后台线程全部放到一个靠数据最近的核上，这样可以让它访问数据速度更快。

第三个是binlog冷热分离。我们实际上除了把日志放上去了之外，还可以把binlog放上去，大家知道binlog写入的量也是蛮大的，尤其是在高负载的情况下。通过把热日志用PMDK的接口存到新硬件上来加速性能。右边这张图表是我们做的一个性能测试，单机场景下的话，如果日志放到新硬件上去的话，现在有15%的提升。主备场景下的话，把日志和binlog进行刚才所说的优化，可以提升50%的性能。同步的场景下，性能可以提升60%。具体这一块的优化的情况，待会第四场有我们昕龙同学给大家好好的讲一讲，相信大家会很感兴趣。

接下来介绍一个腾讯数据库团队对MySQL社区比较大的贡献，秒加字段。其实秒加字段这个功能是我们腾讯游戏DBA团队开发的。这个功能已经被MySQL官方给放到8.0里面去了。现在我们也把这个功能放到TXSQL5.7里面去了。这个功能解决了大家一个非常头疼的问题，就是加字段。

尤其是DBA的同学可能最头疼的一件事情就是这个。在加字段的时候，但是这张表又特别热，有很多操作在上面。怎么办呢，原来可能要通过PT工具去加，现在你不用通过PT工具去加了，你就直接在数据库里面加就可以了。它只需要修改数据字典信息，不需要拷贝数据。图上的这张表有几十个G，加一个字段几乎不需要时间。之所以能够做到这个，是因为我们对数据文件的解析做了一些处理。

也就是说我们会对表里面的数据进行区分，哪些数据是加字段之前的数据，哪些数据是加字段之后的数据，进行一个判断。这样的话，我们在没有数据拷贝的情况下，我们也能够知道数据是有几个字段。

接下来这个是异步删除大表的亮点功能。我们看到图中的这种情况，这个是磁盘IO的一个监控，里面有一个IO的峰值。这个峰值就是没有优化之前，用户在做一个删表的操作，而且这张表很大。线上很多运维的同学对这种情况很头疼，为什么呢，因为它会瞬间把IO打满，从而影响自己实例其他涉及到IO的操作。

我们现在的做法是先把IBD文件改一个名字，然后通过一个后台的线程异步的把这个文件逐步truncate掉，而不是一下子delete掉一个IBD文件，这样可以避免掉IO峰值，IO曲线会保持比较平滑，最终会把IBD完全删掉。这个功能，我们最近也是在跟官方讨论是不是要放到官方版本里面去。

接下来是一个我们近期完成的功能叫热点更新优化。这个主要解决的是秒杀场景下，高并发性能下降的问题。大家都知道在电商促销的时候，我们有一些商品会拿出来进行秒杀，秒杀对应到数据库就是一个减库存的操作。在数据库的商品库存表里面，大量的用户去并发的做update库存的数量，这时候性能就会急剧的下降。大家看到这个性能曲线，512个链接上来的时候，TPS基本上降到1千以下了。为了解决这个问题，比较典型的做法就是在应用层或者中间件层去做排队操作，减小数据库的压力。

现在我们提供的这个功能是在数据库内核层面来解决掉这个问题。我们这个功能可以做到自动感知热点。它可以自动的感知你哪一行是热点行，然后会对所有这一行的update操作进行排队，让它不要那么快的并发进来，然后造成性能下降的问题。而且我们能够做到一键开启，应用层的SQL不需要任何的更改。

我知道友商也有热点更新的优化，但是他们需要通过SQL告诉数据库，你是要在哪一个主键的记录上面进行排队，我们这个不需要，用户完全不需要改任何应用层的代码，只需要通过一个参数，打开这个参数，TXSQL数据库就会自动的感知到update热点，让所有进来的请求对它进行排队。这个功能是我们近期上线的5.7的版本里面提供。大家如果有兴趣的话，可以去试用一下这个热点更新优化的功能。

以上我主要介绍了一下CDB内核的架构，还有各个模块的特性。还有很多东西我都没讲，因为之前在很多大会上我也有讲过，所以这次也讲太多，只是把其中一些比较重要的部分拿出来给大家讲一下。其他的功能如果大家有兴趣的话，我们可以线下再交流。

第三个部分，内核质量保障。这个不管是我之前的分享还是其他同事的分享都没讲过，主要想介绍一下我们CDB内核在开发的过程之中是怎么样去保证质量的。

首先，我们的内核产品是有一个全流程，自己可以控制的一个质量保证体系。这个体系主要分三个部分，一个是开发的流程，第二个是测试的体系，第三个是质量反馈。

第一个是开发的流程，我们整个开发流程是下面这样一个流程。首先是需求搜集。需求搜集主要来源于客户的反馈，线上客户告诉我们说现在的痛点是什么，我们DBA团队、运维团队也会告诉我们，内核出现怎么样的问题，能不能帮我们进行一些优化，或者这个功能能不能帮我们做一做，也包括市场的调研，还有我们自己内部的分析。因为有些东西的话，客户可能没想到，但是我们因为对内核比较了解，会想到这个东西可能是客户需要的，或者这个东西我们可以优化一下，这就产生了需求。需求产生了之后，我们会对所有的需求进行评审。

因为我们数据库内核团队还是有一些比较资深的内核开发人员，除了我还有另外一个也是来自于MySQL官方团队的一个同事王少华，上周他做了CynosDB的演讲。还有诸如张青林，李昕龙等等，这些都是比较资深的数据库内核开发的同学。通过我们这些比较了解数据库内核的人的一些分析和评审，然后落实，最终形成一个开发的计划。接下来就是进行设计开发了，从整体的架构，实现方式到代码完成这个阶段的话，我们也会有一些诸如代码分析会，小组讨论这样一些方式来对整个开发的过程进行优化。

第四个阶段就是测试评审，这个非常重要，这个是最重要的一块。第一步当然是开发完之后，这个功能开发完之后，由开发人员自己写一些单元测试，他自己做完自测之后，还要放到我们的测试系统里面。我们现在已经构建了一个比较完善的测试系统，会全面的对已经完成的代码进行自动化的测试。

自动化的测试主要包括功能测试，稳定性测试，压力测试和性能测试。这些测试都会用到一些比较成熟的工具，比如说sysbench，TPCC，还有比如说RQG，RQG是官方团队用的比较多的一款随机SQL的测试，它主要是自动的产生一些随机SQL，把它发给数据库，看会不会出问题。还包括压力测试，长稳测试等等。做完这一整套测试之后，新版本内核会灰度上线。我们把做完的版本放到某些灰度集群里面去，让我们的目标用户进行试用，或者给我们一些反馈。

如果有问题的话，我们立即修改。这个基本上就是我们的一个开发流程完了以后的一个测试体系，包括我们的研发自测、自动化测试、版本测试和灰度上线测试。

最后一点是质量反馈，我们要对测试和客户使用中发现的问题快速响应，立马解决。因为有一些线上问题，如果是影响到客户线上业务的话，我们肯定是7×24小时在线去解决掉这类问题。待会我会讲一个例子，介绍一下我们怎么样去发现问题，解决问题的。

现在我们讲一下现网问题的响应体系。首先我们内核团队有一个7×24小时的在线的保障体系，每周会有一个同事做主力值班，还有一个备份的同事。当然现网问题多的时候，备份的同事也要上去解决问题。除了值班之外，我们还有一些监控系统。

像图中最左边是我们的CRASH实例监控系统，它会不停的去扫描我们现有的实例里头哪些有CRASH发生。有CRASH发生的话，会报到我们这边来，我们要上去进行分析，它为什么会CRASH，解决办法是什么。

中间这个是一个慢查询告警系统，这个也就是说当客户的慢查询发生到一定的频率或者超过某个阈值的时候，它也会告警。还有一个是我们的秒级监控系统，它会不停的去采集实例上的状态信息，比如说有多少个事务在等待。比如说有多少慢查询等等，它会把诸如此类的这些状态信息抓取出来，放到后台的一个系统里头去。然后我们就可以很直观的从这些状态信息的图表里头看到目前这个实例的运行状态。这也能够帮我们分析一些问题，比如说突然发现某个实例卡住了，它为什么卡住，我们可以通过分析这个图表来进行分析判断。

最后一部分也很有意思，针对于线上碰到的问题，我们会把它做好记录，每一个问题都会详细的记录它是什么时候CRASH的，在哪个实例上面，为什么CRASH，最后是怎么解决的，并且做好分类，给它打标签，比如说它是一个InnoDB存储引擎的锁等待问题，还是复制里面的一个中断问题，我们会分类好，形成我们自己的知识库，并且跟大家一起分享。

以上，大家可以看到我们平时的工作当中是怎么样对整个CDB的内核进行质量控制的。

接下来我会讲一个我们最近经历过的一次实践过程。

这件事情可能大家也有看到相关文章，微盟的一个兄弟成真对整个微盟上云的过程做了一个详实记录，介绍微盟是如何迁移到腾讯云的CDB上面的。大家都知道微盟几个月以前碰到一个黑天鹅事件，比较惨痛的一个教训。好在最后数据都都恢复回来了。痛定思痛，微盟的技术团队决定为了数据的安全还是把数据都迁移到腾讯云CDB上面来，所以我们也非常感谢微盟对我们的信任，他们把最重要宝贵的数据放到CDB上面。

首先，我们要做的一件事情就是把微盟自建数据库上面的所有数据迁移到腾讯云CDB上面来。在做迁移的过程之中，不是直接把数据导过来就OK了，我们做了大量的测试。测试方法并不是跟普通用户一样做一些整体验证之类的，而是把一条一条SQL语句拿出来，然后用mysqlslap进行压力测试，然后对比自建服务器有没有性能上的差异。测试过程中，我们发现有一些语句在自建服务器上面运行只要0.1秒，跑到我们CDB上面来就要差不多1秒钟或者2秒钟才能执行出来。

整个时间线是这样，8号发现一些性能问题1，然后第二天我们内核组就成立了专项小组来进行分析和验证。10号21点就确认了问题原因，进行第一版的优化。后面就接着进行测试了，接着往下跑了。到了14号23点又发现一个新的问题2，然后这一块分析的时间比较长，23号做了第二版优化。25号开始迁移了，26号又发现了一个新的问题3，26号做了第四版优化，最后完成。整个时间大概前后不到20天。但是我们CDB内核的好几个同事都熬了几个通宵去做这件事情。

我们在做这件事情的时候，分析问题用到哪些工具呢？一个是perf，这是一个性能分析工具，它会分析那个函数调用占的CPU的时间。第二个是PT-PMP工具，它也可以用来排查大并发情况下的性能瓶颈。第三个我们刚才看到ORZDBA这个秒级监控工具，它实际上会去看某个SQL的性能怎么样，当前数据库的IO是怎么样的，诸如此类的一些信息。最后就是我们CDB内核团队进行一些源码级别的分析。

接下来看一下我们具体都碰到一些什么样的问题。第一个问题，NUMA绑核问题。这个问题大家也应该会看到一些相关的资料，实际上MySQL之前对NUMA架构支持得很不好。当打开NUMA的时候，CPU被分成多个group，每一个group对应一块内存，那一块内存就是反应速度很快的。如果是这个group的CPU要访问另外一个group的内存的话，它是不能访问的，它是通过交换区去访问，所以这就会造成性能的急剧下降。

这个问题实际上就是我们腾讯云的cgroup隔离策略和微盟原来的隔离策略不一样导致的。它使得TXSQL进程去跨group访问内存，从而导致性能问题。办法实际上就是我们去调整这个绑核的一些配置，然后让内存和CPU更好的匹配，这样就解决了内存访问的存在的性能问题。这是第一个问题。

第二个问题是网络问题。可以简单说一下，因为这个不是我们内核的问题，原因就是它并发增加的时候，mysqlslap这个工具变成短连接了，它就不停的去重连。执行完一个SQL就重联。网络延时对于这种压力下的比较敏感，一旦你网络不大好的话，它就会造成性能的下降。后来调整的办法是把这几个相关的操作系统参数进行了调整。

第三个问题，这个是我们花了非常多的时间去解决的问题。前前后后花了三四天的时间，熬了好几个通宵。这个问题是在执行一个SQL的时候，执行某一个函数性能上有差异，而且是跟官方的版本比，我们TXSQL跟MySQL官方的版本比有这个性能差异。我们还觉得奇怪，因为这一块我们好像没改什么东西，跑同样的SQL语句为什么就差那么多呢？最后我们定位到是我们做的某一个优化导致的。

但是这一个优化有几千行代码，我们不确定到底是哪个地方导致的，只能够一步一步去缩小这个范围。几千行代码，我们先缩减到300行，然后200行，最后实在缩减不了了，我们只能去一行一行看，分析这200行代码里面哪一块代码有可能有问题。最后就发现是我们这个优化里面，有一个计数器，这个计数器很简单，就是一个简单的加一操作，但是由于整个操作调用非常频繁，所以对整个SQL语句的执行性能有很大的影响。最后是怎么解决问题的呢？实际上官方是有一个修复的，就是把这个计数器分区减少了计数器加一时候的并发冲突。

解决掉这三个问题之后，后面基本上我们CDB的性能比原来微盟自建的数据库有比较大的提升。性能下降的语句基本上是没有了。这整个过程，我们为客户提供的服务还是得到了微盟方面的充分认可，所以他们也特别发了一篇文章在这个链接上，大家可以去看一下，整个过程是什么样的。

好，今天我要分享的内容就到这里，谢谢大家，有请主持人。

Q：CStore引擎，目前线上是否可以试用。另外，有没有相应的一些客户案例，以及跟我们的innoDB的存储引擎是否可以并存？

赖铮：很高兴大家对这个CStore引擎很感兴趣。因为它是放在TXSQL8.0版本里面的，8.0正在进行紧张和严格的测试，CStore也放在一起进行测试，所以到时候CStore会跟我们的8.0版本一起发布，应该也就在近期了，也就是这一两个月的时间。到时候可以欢迎大家来试用一下。

第二个就是说这个CStore跟InnoDB能不能共存，是的，是可以共存的。CStore是相当于另外一个存储引擎，它可以跟InnoDB放在同一个实例上头，也能够跨引擎进行查询，实际上就跟MyISAM和InnoB一样，可以做JOIN操作，查两张不同的表，这两张不同的表来自INNODB和MyISAM，或者CSTORE。但是它只是可以，我要特别说明只是可以，但是性能怎么样，这个要具体看情况。

Q：热点更新的一些检测的相应的机制。其次就是说这个功能，它是在引擎层还是在服务层来做的优化？

赖铮：首先说明这个功能是在InnoDB里面做的，在InnoDB的行锁系统里面。大概的检测机制就是说我们会去看InnoDB里面在某一个行上面的行锁个数是不是超过了设定的一个阈值。如果超过了设定的阈值，就认为它是一个热点行。这样的话，会让后续的这一行进行加行锁操作的这些事务进行等待。所以是在引擎层面做的，不是在服务层做的。

Q: 审计日志目前是存到存储文件，还是说会存到一个集中化的存储，类似于一个数据库。一方面是存储，第二个是说审计的插件对业务的性能影响有多大？

赖铮：是这样，首先审计的记录是由后台线程把它刷到一个文件里面，然后由审计代理去读取这个文件，并且把这个文件里面获取的审计信息传到另外一个数据库里头。这个数据库不是CDB了，是我们专门用来存储审计记录的一个数据库。

另外一个问题，对性能的影响。我们测下来如果是打开审计，然后不设审计规则的话，基本上没有太大的影响，只是1%、3%之间的这种性能损耗，它只是把所有的SQL信息记录下来，这个没有太大的损耗。但是如果有审计规则，就是说设定了规则说要审计某一类的SQL，这里面就会对性能有一些影响。我们测下来的话，简单规则可能在5%-10%之间，如果设置了比较复杂的审计规则之后，会有5%-10%之间的性能影响。

Q: 秒加字段的特性，它是不是受限于，比如说需要去一些默认，类似于要添加默认字段，是不是需要做初始化？

赖铮：我明白他的意思，你秒加字段是不是可以设置默认值，这个是我们支持的，我们支持设置默认值。也就是说你在设置秒加字段的时候可以设置默认值等于多少。

Q：另外这个秒加字段目前是哪个版本可以支持到的一个特性？

赖铮：也是5.7。就刚才这个秒加字段是不是可以设默认值的这个问题可以看官方的文档，官方的文档跟我们应该是一样的，它也是可以设置默认值的。

Q: CDB目前或者是将来一些发展的方向是什么？规划这一块希望赖老师也能从CDB的整个架构给一些回答。

赖铮：我们CDB将来的规划的话，就像刚才我提到的，第一个，我们有针对于不同场景的一些不同的产品，比如说我们除了CDB之外，还有我们的CynosDB，CynosDB有更好的可扩展性，在云环境下有更好的可扩展性。第二个是我们会不同的去吸收新技术，去不停的优化我们的CDB内核产品。比如说我们会采用这种跟AI技术结合，比如说我们会在新硬件上进行进一步的优化。比如说我们还会对我们自己内核的系统里面进行一些根本性的优化，采用一些新技术对内核产品进行优化。这是我们将来大概未来的两三年之内要做的事情，不停的去吸收新的东西，不停的把我们的产品一步一步的做得更好，去适应整个云上的环境。

Q: 5.5版本要分析到我们的CDB，比如说5.6甚至5.7，那么需要注意的一些点，比如说因为我们5.6、5.7，默认是支持InnoDB引擎的，用户以前的任务可能会用到这个表，这个时候自动转换之后，可能的一些问题点，比如说我们5.6或者5.7的这些内核有没有去做一些相应功能的优化。赖老师能不能简单做一些介绍？

赖铮：是这样，针对你刚才讲的这个问题，比如说迁移过来的时候有一些memory和MyISAM表，这些表我们是建议用户全部在迁移到5.6、5.7上的话，都全部转换成InnoDB的表。因为最主要是从数据安全考虑，因为大家都知道MyISAM跟memory引擎是不支持事务的，它就不保证数据的完整性。你一旦发生CRASH，那有可能就有数据丢掉了。对我们来讲。所以我们是建议大家都把memory和MyISAM表都转换成InnoDB表放进来。另外一个点是除了这个，还有一个跟复制相关的。因为memory和MyISAM的表，通常情况下如果要做复制的话，如果一旦出问题的话，就会导致复制中断。一旦复制中断的话，因为主从不一致了，从机就提供不了服务。所以这也是一个需要把它转过来的一个原因。在转过来的过程之中，可能你要注意到一些问题。有一些SQL语句可能过不了，那么就需要具体看它到底是什么原因过不了，然后分析一下，然后再把它优化一下，就可以迁移过来。

Q: 基于目前CDB的内核架构是否能完全去满足我们云上用户的一些业务场景,是不是有一些无法去解决现在云上用户的一些痛点？

赖铮：是的，我是这样想的，任何一款数据库产品都不可能做到万金油一样包打天下，总归是有侧重点跟他能够解决问题的场景的，每一款数据库产品都是这个样子，所以会有那么多种不同种类的数据库。同样的，我们TXSQL内核也是一样的，我们可以解决80%以上数据库的使用场景，但是剩下的，或者是有一些东西我们还是做不到的，那可能就需要像CynosDB这种产品来进行填补。CynosDB，大家可以去看一下资料，它是一个云原生的数据库产品，它是存储和计算分离的。这样的话有更好的可扩展性。因为我们现在碰到一个很大的问题就是这个样子，有些用户实际上我只要存储，我的数据量很大，但是我基本上不做太多的查询，我就是要把这些数据存起来。如果你这样的话，你买一个大规格的产品就很不划算。CDB解决不了这个问题，而CynosDB就能够解决这个问题。你想要扩展你的计算能力，打比方说你觉得CPU不够了，我要扩展计算能力，你就买计算节点就可以了。如果要扩展你的存储能力，你买存储节点就好了。对腾讯云来说，也不浪费，大家双赢。所以，我们要在解决问题的同时，大家的成本都能降低。

Q:基于这种主从复制，这种延迟的问题，CDB有相应的解决方案吗？

赖铮：是的，今天我这里没讲，因为过往讲的太多了。讲我们复制这一块的优化。我们复制这一块的优化，就像我们刚才讲的，在半同步复制插件里头，我们还是做了很多不同的优化的，比如说为了支持这种金融场景下的应用，我们就势必要支持主从强一致性。加了强一致性的话，因为强一致性的话就势必会造成一个性能问题，因为你主上面一定要等SLAVE那边同步好了之后，你才能够做。这个性能问题的话，我们又通过诸如把IO thread进行拆分，还包括并行复制优化等等，现在基本上能够满足线上的大部分需求。但是就像你刚才说的一样，因为CDB还是基于binlog的复制，不管怎么说，它肯定是没有基于redo log的复制快，因为它要解析binlog。我们最终解决问题的办法是基于redo log的复制，就是我们CynosDB现在已经做完的事情。CynosDB就是基于redo log的复制，效率就非常高了，它直接可以应用redo日志，不用去解析binlog，快很多。所以我是觉得CynosDB是下一代的产品，是非常有朝气和非常有前途的一款产品。

特惠体验云数据库 

↓↓更多惊喜请点这~