相比原生，腾讯云数据库MySQL 8.0带来了哪些新的极致体验？

导语 | 腾讯云数据库 MySQL 8.0 版本于 2020 年 7 月正式发布，QPS达到 70w+。腾讯云基于官方 8.0 版本新增什么特性和功能，这些新能力为B端客户带来了哪些实际的价值和帮助？本文是对腾讯云数据库产品专家黄稚禹在腾讯云开发者社区沙龙online的分享整理，希望与大家一同交流。

一、腾讯云MySQL8.0企业特性

1. 官方 MySQL 8.0 新特征

官方MySQL 8.0 是非常大的版本，以前的版本号是 5.6、5.7，现在一下飞跃到 8.0，对于 Oracle MySQL官方来说也是非常大的版本，有很多的更新。

在官方 8.0 版本里，一个很重要的特性就是秒级加列，在加列的时候不再像以前一样拷数据，只需要修改数据字典就可以快速实现加列。

另一个比较重要的特性就是新增了窗口函数功能(Windows Function)，可以实现若干新的分析统计查询功能。它不是将查询结果合并放入某一行，而是将结果放回多行中，可以大大提高分析型业务场景的效率。

熟悉 Oracle 数据库的朋友们应该会对窗口函数比较了解，报表统计分析的功能非常方便，有了窗口函数特性，MySQL 8.0 就可以为企业业务增长助力。

第三个特性是Atomic DDL（原子DDL）。在8.0之前的版本，在做一些操作时如果失败会有状态残留。比如truncate一张上亿行数据的表时，如果失败了中间的残留状态可能需要在源代码层面去解决。而借助8.0的新特性，可以确保相关DDL操作的顺利完成，避免出现中间的残留状态。

第四个特性是JSON improve（JSON增强型改进）。在 MySQL 5.7 开始，就提供了 JSON 字段的数据类型，在 8.0 中对该功能进行了更大的改进和拓展。

这个功能的出现对 MySQL 具有深远的意义，因为它消除了很多企业对独立的NoSQL文档数据库的需求依赖性。

比如一些游戏行业对 NoSQL 有很大的需求，因为其支持 JSON 字段，但是 MySQL8.0 引入了 JSON 字段类型以后，结合自身 ACID 的特性消除了对独立文档数据库的依赖。MySQL 8.0 把包括 schema-less 模式的存储数据类型全部进行了统一。

官方的特性还有很多，比如 CTES 公共表达式、直方图等，让表的数据分布统计更加的准确明显，还包括降序索引、隐藏索引的特性等等。

2. 腾讯云 MySQL 8.0

腾讯云 MySQL 8.0 推出八大特性：数据加密、SQL审计、线程池、数据强一致性、新硬件支持、轻量级 AP 、热点更新、SQL限流，下文我们详细来做解读。

（1）SQL审计

MySQL 开源社区版是不支持企业级审计功能的，只有商业版里才提供。而腾讯云 MySQL 8.0实现了内核级别的审计功能，并且结合了云产品进一步提升了 SQL 审计功能，让用户拥有更好的体验。

上图展示了腾讯云 MySQL 8.0 的审计架构图，用户连接 session 产生的审计记录，由专门的写盘线程(Flush thread)将内存中的审计记录写入审计文件中(Audit File)，直接落盘。

而审计代理(Audit Agent)则会读取审计文件，将审计记录发送到审计日志中心。审计日志中心是由 CTSDB 数据库存储的，这是一个时序数据库，贴合时序审计的数据存储。

选择这样的数据库存储能带来很多好处，首先是数据压缩率高、二是数据吞吐量大、三是分析能力强，完全可以满足海量审计数据下的分析处理能力。

同时我们也会采用 JSON 格式对审计日志进行存储。记录的审计内容有时间戳、影响行数、执行时间、主机、来源IP、实例名、用户名、数据库名，包括具体的 SQL 语句和类型等。

考虑到审计日志量巨大，我们也在产品层面上提供了审计规则的过滤。另外，为了减少审计的打开对 MySQL 数据库的性能影响，目前只会对命令执行完后的结果进行审计。

根据测试，如果打开审计并进行全量审计(Audit All)，会达到 6% 左右的性能损失。而采用过滤型审计性能损失大概是在 2%~3%，相对于官方商业版本损失也是比较小的。

我们的审计功能还在不断往前迭代发展，现在只是对事后操作进行审计，目前正在开发一项新的功能：事前拦截功能。

以前 MySQL 中有许多大数据是最让 DBA 头疼的，就是主实例大事务容易造成主从延迟等问题。事前拦截功能，会针对不同语句进行并发控制，从而保护核心任务。事前拦截也会配合 5.7 版本出现的新参数 —— 最长时序时间(max_execution_time)。时序时间超过设定值，就会启动拦截。

（2）线程池

对于线程池，之前 MySQL 默认的连接处理方式是：一个线程一个连接，每个数据库连接都会创建独立的线程，请求结束后就把线程销毁，这个模式相较于最早期的进程服务在效率上有了很大提升。

但是在互联网高并发业务场景下此模式就有很大的问题，因为高并发模式会创建大量的线程，线程会不停征用 CPU 资源、导致 CPU 频繁进行上下文切换，很多短连接也会出现线程频繁的创建和销毁，这些操作都会额外消耗 CPU，导致资源的浪费甚至引起数据库的高负载。

腾讯云数据库 MySQL 8.0 针对这些问题进行了线程模式的改进。当客户端发起连接后，由空闲的线程先对请求进行处理，减少上下文切换的消耗和创建销毁的消耗。同时引入了多队列的机制。

多队列的好处是，可以按照业务的访问走不同的队列。比如写业务、读业务可以分别在不同的队列，大家相互不干扰，各自排队处理请求就可以了。

如下图所示，在开启了线程池以后，512 高并发线程下性能还有提升，但是在没有开启线程池模型的情况下，线程到 512 以后性能开始陡降。

（3）数据加密

MySQL 5.7 以后就开始支持 TDE 透明加密的数据体系。腾讯云 MySQL 8.0 在此基础上引入了腾讯云的另外一款产品 — KMS。KMS 是腾讯云提供的密钥服务，是一项单独的产品，除了与数据库，还可以跟其他云产品相结合使用。

通过 KMS和 TDE 的深度集成，实现了二者的结合，为腾讯云 MySQL 用户提供了一整套安全解决方案。

KMS 采用的是两层密钥体系。KMS 涉及两类密钥，即用户主密钥（CMK）与数据密钥（Datakey)。用户主密钥用于加密数据密钥或密码、证书、配置文件等小包数据（最多 4KB）。数据密钥用于加密业务数据。

海量的业务数据在存储或通信过程中使用数据密钥以对称加密的方式加密，而数据密钥又通过用户主密钥采用非对称加密方式加密保护。通过两层密钥体系，确保数据在在内存和文件中都进行加密。

同时，我们也基于云上的访问控制权限体系——CAM，和MySQL加密体系打通。引入以后，根帐号的管理员可以设置多个子帐号，可以为子帐号分配部分权限，把最高级的权限集中在根帐号用户手中。

（4）新硬件支持

同样，腾讯云 MySQL 8.0 在新硬件的探索和适配上也有着重要的进展。

目前主流云厂商的关系数据库都在使用 SSD，但现在市场上已经存在一种新的硬件—— AEP（英特尔推出的固态存储介质），它提供了超过普遍 SSD 甚至更高级别 SSD 的数据存储能力。

根据英特尔提供的性能指标，AEP 最高的读写速度能达到 8.3 GB/s、写入速度3GB/s，远超现在 SSD 固态盘或者 PCIE 固态盘的性能。

腾讯云 MySQL 8.0 对 AEP 文件读写接口进行了适配，提供在 AEP 硬件适配下的性能改进，把 relog 放到 AEP 硬件上做测试，发现在同等规格操作系统条件下，AEP 性能大大高于传统 SSD 。

经过测试，腾讯云 MySQL 8.0 和官方 8.0 版本在性同硬件、同规格实例、同操作系统条件下，性能全面超越了 Oracle 8.0 。

二、腾讯云内核 TXSQL

1. TXSQL是什么

为什么腾讯云 MySQL 8.0 性能可以超越 Oracle 原生版本？这是因为腾讯云有专门做内核的数据库团队，相当于腾讯云内部有一个能够去做 MySQL 源码分支技术研发的专家团队。

我们的内核叫做 TXSQL，项目团队在十几年前就已成立。团队的工作是在原生内核源码深度下做项目定制，对官方版本进行二次开发。除了支撑腾讯云数据库 MySQL 的平稳运行，也以打造国产数据库 MySQL 分支为已任。

当然，我们目前跟其他耳熟能详的 MySQL 分支(比如：Percona和MariaDB)比起来，仍然处于一个相对的稚嫩阶段，但是内核体系业已搭建发展起来，腾讯也会不断致力于发展国产数据库。

2. TXSQL演进之路

如上图所示，腾讯云 MySQL 的内核在每一个版本都做了很多改进，不断修理官方Bug，加强性能以及做企业级功能的适配。

我们从官方 5.1 版本的时候就在不断跟进，会选择一个经典稳定版本做为基础版本进行开发。所以我们是一个在内核层面能够自主可控的厂商，因为内核都是我们自己写的。

但我们现在还是发展过程中，当到了某个阶段，我们也会把TXSQL开源出来提供给大家，到时即便不是腾讯云数据库用户也可以用上TXSQL，也可以用上国产数据库内核级别的软件，这将是一个非常有意义的事情。

3. 历史发布的优秀特征

在8.0的版本之前，TXSQL也发布过一些优秀的特性：

（1）异步大表删除

在日常运维过程中，当删除一个大表时（如一个 20 G 的 ibd 文件的大表），在删除这个大文件的过程中，文件系统 IO 达到峰值，持续好几秒，这样会导致文件系统无法响应其他数据库实例的 IO 请求，对上层应用表现为数据库无法响应。

在有些业务中，如果有好几秒数据库没有响应，就是很严重的事故。为了让删除大文件的 IO 更平滑，运维人员总结出一系列的操作，以降低系统级不可用的风险。但这这些做法缺少统一的模式，以及操作上的不确定性。

TXSQL 在内核实现了异步删除表的功能，通过自动化的方式，减少人为操作中可能犯的错误。其通过分离数据文件，将原有的数据文件脱离 MySQL 系统，并建立后台任务，将文件的删除转化为文件的逐步回收，当数据文件进入低风险大小后，完成最后的删除动作。

这种分散的操作，极大的分摊的系统开销，提供系统的可用度。对于用户来说，可以通过简单的开关模式，动态开启或者关闭该功能，就可以使用 TXSQL 提供的该项功能，极大的避免起停服务，导致对业务的影响。

（2）GTID 复制功能扩展

GTID 模式下复制支持 create as select,create/drop temporary table, 同时能更新事务表和非事务表等语句。适用场景如下：

• CTAS 操作频繁场景，无法优化 CTAS 为先建空表，再 Insert 的业务场景；
• 大量使用临时表场景；
• 更新 MyISAM 表场景 无法使用 GTID 问题；
• 内核层级新增参数来控制开关。

（3）复制限速

在 MySQL 的主从之间，一般原生的是通过获取 node 来访问主从复制，但这样就会带来一个问题。就是在主从之间（也就是 master 和 Slave之间）新建了一个实例，如果中断时间比较长，而你的网络刚开始恢复的时候，它会瞬间把你主从之间的带宽给打满，这可能会影响到其他一些正常的业务逻辑。

为了避免类似这样的问题，TXSQL 提供了一个限速插件。这个插件在主从同步的时候，可以设置阈值。因此即便在这种情况下，也可以保证为业务应用预留一定的带宽。

在实现上，TXSQL 采用对线上业务影响最小的 Slave 端限速的方案。该方案下，只需原地升级 Slave，不会影响线上服务，在确保不停服务的前提下，这个方案更容易被业务方接受。

实际的限流算法采用了经典的流量管控算法—令牌桶的模式，该算法更适于流量不稳定的网络模式，让流量更平滑，这种不稳定的处理方式对于 TXSQL 所面临的复杂应用场景有更好的应用，避免了前面所描述的可能的突发流量导致服务器的可用性降低。

（4）Redo log 双缓冲区

MySQL redo log 是一个顺序写的单缓冲区，log_sys->mutex 锁资源竞争激烈，在事务落盘的过程中对 LSN 相关的读、写都被堵塞，为了解决 log_sys->mutex的锁 竞争问题，引入双缓存机制 &w_mutex 锁，在 flush redo log 的过程中释放 log_sys->mutex，继续持有 log_sys->w_mutex，从而堵塞写，不堵塞 LSN 相关的读操作，flush 完成后释放 w_mutex；从而提升并发性，提升性能。

4. 腾讯云MySQL设计理念

腾讯云的MySQL数据库底座因为有内核团队做支撑，并且在上层有非常强健完善的管控系统，可以做 HA、储备切换、备份、迁移存储、迁移升级等等的操作，这些一起组成了腾讯云数据库的 MySQL 服务。

腾讯云数据库的MySQL设计理念总结下来，就是数据强一致，满足客户的高性能需求，在安全性方面也必须得到保障。还有就是云上数据库的重要特性：具有良好扩展性，可以快速进行扩容、增加实例，进行纵向和横向的扩展以及便捷的运维。

另外，腾讯云 MySQL 周边也有很大的工具体系，比如和 DTS 数据迁移、智能管家 DBbrain 结合在一起，形成了一整套腾讯云数据库服务。

腾讯云数据库的架构默认是一主一备，但也支持一主两备三节点金融版的架构。在这个基础上，我们还可以进行扩展只读实例(下图左)，方便用户读写分离，也可以扩展灾备实例(下图右)，实现异地灾备，异地多中心的架构，形成完整健全的HA的切换，保证用户在HA切换的同时地址不变更，数据也不会丢失。

三、腾讯云MySQL8.0行业场景

1. 电商场景应用

腾讯云在电商行业有非常多的客户，电商客户的需求和痛点我们体会得比较深。前不久6.18的时候腾讯云 MySQL 也支撑了很多电商的大促，其中秒杀是常见的场景。

秒杀发展到现在，其实已经不只是电商场景在使用，其他比如抢红包，春运抢票等也属于秒杀。

秒杀场景的特点有三高，分别是瞬时并发性高、数据一致性高和热点更新频度高，商品要频繁进行库存加1或减1的操作，会给企业级数据库造成巨大的压力。大量的数据更新并发度，按照MySQL数据结构和引擎的特点容易产生数据库的行锁等待，导致数据库性能持续的下降。

腾讯云MySQL8.0针对电商场景秒杀进行了专项优化，帮助客户任何秒杀的场景都可以稳如泰山。

8.0 电商场景里做的第一个优化是热点更新，热点更新可以大幅度优化对单行数据的频繁更新，在控制台一点就可以开启热点更新，内核系统会自动探测是否有单行热点更新，如果有的话，会让热点更新的用户线程排队以减少大量的行锁，以减少并发性能的下降。

如上图所示，开启热点更新功能后，在高并发的情况下，MySQL性能有数十倍的性能提升。

第二个优化是SQL限流。

大家知道，当数据架构上层的缓存(比如Redis)透传后，海量的SQL访问一下子涌入MySQL，会导致一些极端的现象，可能导致MySQL数据库性能的急剧下降和连接数打满。

腾讯云MySQL8.0的SQL限流功能，会针对性对超高并发度 SQL 进行限流，避免 MySQL 系统性能下降或连接数打满。该特性也集成到腾讯云数据库智能管家 DBbrain 中，用户可灵活进行 SQL 限流的配置。

该项功能主要通过限制某些 SQL 语句的操作，来避免 SQL 语句使用不当所导致的系统资源占用过大，导致系统整体性能下降或假死的情况。通过云上控制台的简单配置，即可完成对指定 限流 SQL 语句关键字的匹配以及限流方式，非常灵活便捷。

第三个优化是多队列线程池，因为有多队列的模型，可以超高并发下使用线程池技术让MySQL性能不减，减少线程频繁的销毁造成的CPU切换。在大规模连接和复杂混合 SQL 模型下，保持 MySQL 持续稳定。

通过腾讯云MySQL8.0的SQL限流、热点更新和多队列线程池三大技术功能保障，让秒杀场景下MySQL数据库持续稳定运行。

除了这三大优化外，腾讯云MySQL还有很多企业级产品能力支撑电商行业，比如老牌的功能：只读实例，可以挂多个只读实例进行负载均衡，方便用户读写分离。

另外还有置放群组功能，置放群组是一个分散部署，保障MySQL高可用性的产品功能。有客户会担心一台物理机上部署的都是同一个客户自己的MySQL实例，如果这台机器挂了，那这个客户的实例就会全部挂了。

通过置放群组功能可以把同一个客户的多个MySQL实例水平分布到不同的物理机中去，这样可以很好保障这个客户的所有MySQL实例的可用性。

2. 游戏场景应用

游戏行业的特点首先是部署能力要快，游戏行业经常的开服合服，一旦有服务器不活跃了就要开新的服。

二是游戏行业要求对数据库回档能力要求非常高，原因是有些游戏行业可能遇到数据道具的回溯(比如：遇到外挂或游戏异常)。

三是大型游戏是要出海的，讲究全球同服，多地的数据要能够同步，玩家要就近接入访问，保障竞技公平性。不可能让新加坡玩家访问广州的服务器，这样延时太大，游戏玩家也会投诉。

另外，游戏行业数据的存储需求灵活多样，传统的MySQL存储是二维表，每添加一个属性就要加字段、修改字段，或者把字段删除，这对游戏行业来说并不友好。因为游戏行业每一行数据结构都可能不同，游戏行业有很多道具和玩家角色的需求，数据存储特点上属于schema-less架构。

基于这样几个行业特点，腾讯云MySQL8.0在JSON数据类型上进行了扩展，丰富了游戏业务上的灵活性和支持。比如玩家的道具、玩家的角色属性都可以放一个JSON字段中去存储，同时提供丰富的JSON函数去读取游戏属性的数据。

当然，MySQL 8.0 比其他的版本在加字段上也更友好，因为加列是秒级了，但是要修改一些字段的属性肯定还是不如直接用JSON数据类型更加的方便。

二是腾讯云MySQL在回档的基础上强化了恢复功能，可以从物理备份里快速把备份克隆为一个新的实例，可以按时间点进行克隆恢复，这样对游戏行业比较友好。开一个新的服务，拓展一个新的同类型的游戏时候使用克隆实例功能，一键可以完成数据库的拓载。

三是腾讯云 MySQL 8.0 提供跨可用区部署主备节点的功能，因为游戏行业对高可用要求非常高，也有容灾切换的诉求，8.0 主节点和备节点可以放在不同可用区，主库广州三区、备库在广州四区，即使三区整个可用区挂了也可以无缝的为游戏提供服务。

以上就是腾讯云 MySQL 8.0 对游戏行业的赋能。

3. 金融场景应用

金融行业最大的两个诉求，一是数据一致性，一条数据也不能丢，因为一条数据往往意味着大几十万、几百万金额的订单。

二是金融行业需要高安全，金融行业不仅仅是对自身业务有安全诉求，同时也有监管的需求，国家的银监会、保监会会对金融行业有安全门槛设定，不然政策上首先就能把金融业务卡住。

我们针对金融场景也做了定制优化，首先是 TDE 透明数据加密，结合云上KMS和CAM访问控制系统进一步强化了数据安全的保障，用户可以把自己的密钥导入进来，也可以用云上密钥。还可以区分根帐号、子帐号，根帐号可以赋予子帐号不同的权限，比如赋予子帐号只能创建实例不能销毁实例，只能下载备份不能删除备份等。

另外，金融行业里面有很多财务对帐和分析统计的需求，金融报表很复杂，之前的MySQL做对帐的功能非常的烦琐。

MySQL8.0提供便于数据分析的窗口函数和 CETS 公共表达式，可以在数据库表里实现复杂的统计功能。只读实例能用腾讯云MySQL 8.0 完成复杂的统计需求，这对金融行业来说也十分友好。

安全性方面更不用说，之前的腾讯数据库 5.7 版本已经满足了需求，比如金融行业最基本的刚需是两地三中心的架构，一主一备、跨可用区和搭建异地的灾备，部署腾讯云数据库可以实现两地三中心的架构，保障金融行业7*24业务的稳定运行。

腾讯云数据库 MySQL 8.0 提供三节点(一主两备)金融版，采用强同步复制模式，更快、更高、更稳的金融企业级服务。

强同步复制需要一主两从的架构，仅需其中一台 Slave 成功执行即可返回，避免了单台 Slave 不可用影响 Master 上操作的问题，提高了强同步复制集群的可用性和性能。

4. 新零售场景

第四个场景，是这几年很火的新零售的场景。比如智慧商超(家乐福)、智慧门店、大型的餐饮连锁(麦当劳)、和最近很火的叮咚到家都属于新零售。

新零售的特点是有一个门店系统，类似传统的O2O，现在具像化成了新零售，线上线下结合形成门店的效应。零售行业中也有会员制，如何通过会员的属性达到会员数据于一体，整合新零售线上线下渠道实现营销一体化，是这些业务架构的特点。

新零售场景下数据库的特点如下： 

• 需要较高的弹性伸缩能力；
• 需要高并发支持；
• 需要数据化运营提升销售、库存、物流等效率。

典型的如商超，这个场景对数据库也有一定的要求，新零售的首要要求是必须把业务中台和数据后台相结合，打破信息孤岛。要去分析商圈和会员的数据，建立很多后端的零售数据分析模型，以方便业务灵活的应对。

针对这种场景，腾讯云 MySQL 8.0 推出了 Cstore 引擎功能，Cstore是列存型的引擎，可以实现高效的中台数据分析和列式存储。

传统的 InnoDB 提供的是 OLTP 服务的存储引擎，适用于事务密集型的业务场景。对于分析型 OLAP 的业务场景，InnoDB 就无法胜任。

通过 CSTORE，用户可以完成大型数据的查询与分析，可以适用于历史存档数据、日志数据、大数据、更新不频繁的 OLTP 数据和数据仓库和分析处理，数据处理量达到 PB 级别。

在性能方面，通过高压缩比、快速加载、针对性的查询优化这些技术实现，向用户提供高效的服务，从而达到单节点可支持百亿行记录的秒级查询。

TXSQL 的列存储可以达到 10：1 的压缩比，通过减少磁盘空间的使用，实现大批量数据的秒级写入和读取。在已有 MySQL 查询优化的基础上，利用多种形式的稀疏索引过滤数据实现高速的数据过滤于选择。并利用多列并行处理的方式，高速完成数据的加载与处理。

除了前文提到的电商、游戏、金融、新零售行业，腾讯云 MySQL 8.0 在其他行业也有着许多应用，为包括交通、文创、教育行业赋能。我们也在积极推进这些行业尽快升级到 8.0 版本，以适配更多优秀的特性。

四、MySQL数据库未来展望

最后想跟大家开一些脑洞，畅想一下未来的数据库会怎样的演进。

1. 云原生

关于腾讯云数据库的未来展望，第一部分是云原生。谁都不否认最近十几年IT技术上最大的变革是由云带来的，而且这场变革的革命仍然在进行。

数据库的未来是云上原生出来的，因为云上的产品本身就很丰富，云上数据库并不是孤岛，云上专有网络有VPC、存储有COS、CBS等，主机有虚拟机CVM，还有各种数据安全产品，云数据库都可以复用这些能力。

比如：数据库备份可以存COS，数据库可以部署在CVM，异地网络可以用云联网打通，负载均衡可以用CLB等。因此，未来的数据库一定在云上，因为结合了其他云上各种产品的能力。

功能的集合将不再局限于一个软件包，以前用数据库就是下个软件包，DBA自己写脚本去备份，去做HA，现在云上本身就有丰富的产品，也就是我们经常说的跨云产品之间的融合。

腾讯云数据库也孵化出了CynosDB这样的云原生数据库。CynosDB是存储和计算相分离的数据库，它解决了弹性的问题。

传统的MySQL在做弹性扩展的时候，有一个痛点，就是必须要拷数据，增加一个副本的时候就得导入备份再追binlog，复制postion追上才算弹性扩容完成。CynosDB存储和计算分离架构，节点扩容不需要再拷数据，因为所有节点都读取的是共享存储的数据，共享存储是多副本的，可以保证存储的高可用。

上层的节点可以很快的扩容，而且是秒级扩容，CynosDB是真正解决MySQL弹性能力的数据库架构，实现了极致的弹性。

另外，CynosDB确实也复用了云上面其他产品的能力，比如:底层存储对CBS进行了深度定制，RDMA网络上的定制，以及复用计算节点虚拟化的能力等等。

2. 超融合

二是超融合，以前大家讲OLTP、OLAP数据库，超融合是把这些TP和AP的数据库都统一起来。

以前要做一个数据仓库，可能要从很多MySQL源库：订单库、用户库和库存库中搞一个多源复制，多个源端复制到汇总分析库里面，这个汇总库就是分析型的OLAP数据库。

这是最早的超融合，TP和AP数据库是分离，通过复制打通。当然，系统复杂点的话，中间可能还有数据清洗、数据映射(ETL的部分)。

这种超融合架构腾讯云数据库也已经实现，比如：我们可以从MySQL InnoDB引擎复制到MySQL Cstore引擎，实现TP到AP之间的复制链路打通。

未来的数据库不用做这么多烦琐的事情，而是把OLAP、OLTP融合在一起形成一个数据库，中间省了数据链路的复制，真正的超融合的方向在一个表里面，一个数据库里面既可以支持行存也可以支持列存的数据。

对于业务层的使用来说，少一个系统意味着更统一的体验和更低的学习门槛和更小改造成本，不要低估统一带来的力量。

3. 自治

最后要说的是数据库自治也就是未来的智能运维，智能运维现在还处在比较初级的阶段：智能诊断上，比如：推荐增加缺失的索引，推荐SQL优化建议等。

当人工智能和AI算法到达一定程度的时，并且给数据库的诊断系统喂了大量的数据后，是能够做到自优化、自诊断、自恢复和自运维的，至少可以把数据库常见的异常问题自行闭环搞定，这也是我认为未来的数据库智能的方向。

现在腾讯云上有数据库智能管家DBbrain，也正在往这个方向走，DBbrain产品里有一个CDBTune的项目，也就是智能调参，我们正在不断的给CDBTune喂大量的MySQL参数优化数据，修正和量化参数优化模型，让它变的更智能、更准确。

4. 未来的未来

前文提到的三个方面主要聚焦在短期趋势上，现在还可以和大家再延展一下，未来的未来是什么样的？

云上技术发展成熟以后，数据库一定可以做到灵活的弹性调度。弹性这个词并仅仅指弹性的拓展，不只是能够很快的升级、添加节点，这只是一个狭隘的弹性。

真正的极致弹性是在此基础上加上“调度”，我们做产品的同时也在思考，未来的数据库能不能自动识别工作负载，自动进行布控。比如能预感到峰值即将来临，自动的采购机器，对热数据创建更多副本并重分布数据，提前扩容。在业务高峰过去后，自动回收机器进行缩容。

未来数据库是否能够感知业务特点，根据访问特点决定分布。比如前文谈到的游戏行业里的全球同服，数据带有明显的地理特征，新加坡一定要搞新加坡的节点，此时系统将自动的将数据的地理特征在不同的数据中心放置。

另外数据库能不能感知查询的类型和访问频度，从而自动决定不同类型数据的存储介质？例如：将冷数据自动转移到 S3 之类比较便宜的存储，热数据放在高配的闪存上，高效的分配资源，让企业的成本降到最低，这也是我们一直在探索做的事情。

5. 新硬件的颠覆

最后说下硬件对数据库的影响，大家可以回顾下数据库发展历史浪潮，最早以前是机械硬盘(SATA盘)，那时候 IOPS 几百上千是很了不起的事情了。

现在来看SSD，NVME SSD这些存储介质，IOPS几十万，上百万都不是问题，硬件一定是能够去颠覆改变数据库行业格局的，

传统的关系型数据库设计理念，写数据都是先写内存，然后再刷脏页刷新到数据文件，中间通过binlog和redo log这样的机制确保事务一致性。为什么都这样做，就是因为早期硬盘IOPS慢，吞吐量低。

假如未来硬盘IO能力达到和内存相媲美的能力，甚至比内存更快，这个时候数据库会是怎样的架构？大家也可以去思考下，可能 buffer pool 这样的组件都会被取缔和颠覆。

当然，硬件技术不像软件技术那么快，会有一个迭代的周期，但是值得我们期待。

Q&A

Q：数据库回档用的是数据库备份+日志，还是有类似 oracle 那样的 flashback功能？能快速查询历史某个时间点的数据？

A：目前腾讯云数据库回档和克隆，用的都是数据备份加追日志的机制。而且我们现在的回档都是基于物理备份。但这小伙伴问了一点说会不会未来有这种 Oracle的flashback功能？我们正在做这样的内核研发。这个功能就是闪回，未来会去实现这样的功能，并且把它产品化，也请小伙伴多关注一下。

针对克隆和回档所延展另外一个问题，就是如何能快速查询某个历史时间点的数据？其实我们也有考虑到，实际上很多用户在使用回档和克隆功能的时候，都会遇到一个问题：「不知道回档到哪个时间点」，不可能每个时间点都去回档，耗时耗力。

所以我们后面会推出一个功能，针对备份池可以查询它有什么样的数据，这样就可以知道这个备份池到底缺失什么样的数据，从而解决这一问题。

Q：实现国内与欧洲数据共享，需要选择不同地区的数据库吗？

A：目前腾讯云 MySQL 实现数据共享，还是需要MySQL的复制功能。以游戏行业全球同服为例，你的主实例可能在上海，这时你可以选择去搭建一个灾备实例，比如选在欧洲的法兰克福，这样你的欧洲业务就可以就近访问实现数据共享。从目前架构来看，还是需要通过数据多节点来实现共享。

Q：CynosDB 和 TDSQL 是什么关系？

A：实际上现在 CynosDB 它是一个云原生集中式共享存储的数据库，底层的数据文件都是落在共享存储里面，上层的计算节点服务的都是这一层共享数据。

当然这里面会有很多保证数据一致性的算法和机制，它可以实现快速开启计算节点，快速获取计算节点所需的 CPU、内存资源，做到秒开节点。

而 TDSQL 是分片分布式架构。比如有一个 32 T 的数据库水平分布 4 个节点上面，每个节点有 8 T 的数据，这 4 个节点都是在不同的物理机器上，它要读取所有的数据的时候会把这 4 个节点数据都读取上来，由中间代理的 proxy 去汇总。

所以说 CynosDB 和 TDSQL 是两款完全不同的产品，它们的架构一个是共享存储架构，一个是分片分布式的架构。

我认为未来这种统一的数据库趋势会比分布式的更大一些， 分布式现在用得很广，但从我们的经验来看，分布式会增加系统复杂度和开销。

因为分布式以后，如何把这些数据都汇总？性能怎么去保障？怎么管理 proxy ？怎样做到高可用？怎么把握分布式事务的一致性......这些都是架构上需要考虑的问题。

当然我不是否定分布式架构，分布式架构的应用场景还是非常多的，我只是觉得在未来它可能会增加客户的一些负担。总的来说这两种战略各有优点，各有不同特点，主要看看适用的产品和业务。

Q：怎么防治删库跑路问题？

A：怎么防治删库跑路，这实际上是一个安全问题。如果你使用的是云上的数据库，因为云上数据库是有 SLA 和安全承诺保障的，数据如有丢失，云厂商会赔付。

但我猜想你的问题是想问：在自建的数据库中心怎样防止删库跑路？首先可以参考云上产品的设计思路，第一点是做备份。一定要有一个健全的备份机制和备份中心，然后备份中心要和现在的数据库实例隔开，备份不能和数据库实例在同一台服务器上。因为如果这台物理机挂了，那么实例和备份就都没了，所以一定要选择第三方备份中心。

第二点就是要搭建容灾体系，比如前文提到的金融行业两地三中心架构，实际上在云下自建环境也可以实现，不过成本会更高，需要去聘请专业的DBA搭建和租 IDC 机房等。

另一点就是权限要避免集中到一个人或者一个团队手中，例如腾讯云就可以利用 CAM 功能把根账号、子账号权限区分开。备份的管理权限和实例的管理权限也不能给同一个人或同一个团队，避免一个人可能把所有的数据、灾备中心、备份中心都毁掉，所以要分而治之。

Q：线程池的线程数可以动态增长吗? 可以配置动态增长的最大线程数吗？

A：线程池的线程数可以动态增长，我们也可以去分配多个队列，而且我们希望这个线程能够灵活控制数量，同时可以配置动态增长的最大线程数。