根据上周，Gartner在Linkedin上的消息，2022年数据库魔力象限正式发布（参考）。先睹为快：原始参考：链接

关于Gartner的数据库魔力象限

Gartner数据库魔力象限（参考，后面简称MQ）一直是数据库领域的年度”锦标赛”，也因为Gartner的专业与专注，其榜单在各个领域都被众多的技术决策者所认可。所以，数据库领域的MQ也就成为了各大厂商年度一场重要的”考试”。

之所以称为”象限”，是因为Gartner将产品/厂商的能力用两个维度去衡量，横坐标是”COMPLETENESS OF VISION”，代表了厂商的”远见/软实力”，或者说是“对领域未来理解判断”，具体的包括市场理解、产品策略、创新能力、商业模式等的理解和策略等。纵坐标是“ABILITY TO EXECUTE”，代表了厂商的“硬实力”，包括产品和服务能力、销售定价、市场响应、客户服务等能力。

这两个坐标组成了以下四个象限：

• 如果”双高”（软硬皆强）那么就是在第一象限，也就是”全球领导者
• “如果”软实例”很强，则会落在第四象限，被称为”VISIONARIES”，译为”远见者”
• 如果”硬实力”很强，则会落在第二象限，被称为”CHALLENGERS”，译为”挑战者”
• 如果”软硬”都相对不算强（注意，这里是”相对”，因为进入了该象限都已经是全球范围内都有竞争力的选手了），那么则落在第三象限，被称为”NICHE PLAYERS”，译作”特定领域者”，这个翻译不是很好理解，其意思有两方面一个是，在某个特定的领域非常强，另外，就是，软实力和硬实力都还相对不算强。不用太纠结翻译

AWS一骑绝尘领跑整个数据库领域

从魔力象限第一军团来看，依旧是AWS、Microsoft、Oracle、Google，相比前一年，第一军团和第二军团进一步拉开了距离，领先后续厂商更多。在第一军团中，AWS也进一步来开了与Microsoft、Oracle、Google的距离。AWS无论从横坐标、还是纵坐标两个角度，都已经是绝对的领先。而在去年，微软在横坐标上是更领先一步的。这就是云计算给数据库领域带来的改变。

在全球市场征战的中国数据库厂商

再来看看中国数据库厂商的表现。

阿里云数据库位置变化不大，依旧是国内唯一的全球领导者。自2018年阿里云首次进入远见者象限，2019年进入挑战者，2020年成功进入了领导者象限，今年已经是连续三年保持在领导者象限。

这次腾讯云也在间隔了一年之后，再次进入了MQ，虽然是Niche Player，但其位置还不错。另外，略有些意外的是华为，这次没有继续保持在MQ中，而在之前2021、2020年华为均在MQ的第三象限。

MongoDB回归，TigerGraph首次进入MQ

MongoDB间隔四年（2018年），再次进入数据库魔力象限。并且出现直接出现在了领导者象限。MongoDB凭借着其在开发者中广泛的认可，和持续增长的营收，对待数据库魔力象限可以说是非常“硬气”的。

另外，分布式图数据库 TigerGraph 首次进入MQ；老牌图数据库Neo4j也再次（上一次是2019年）进入MQ，两个图数据库均在Niche Player象限。

其他

• IBM、SAP和Teradata虽然依旧在领导者象限，但位置与”第一军团”的距离在拉大
• Cockroach Lab作为唯一的独立分布式关系型数据库厂商已经连续两年都在MQ当中，说明其市场和产品能力都受到了Gartner的认可。今年，TiDB和OceanBase都已经开始涉足北美市场，相信也会遇到CockroachDB。此外，TiDB也在今年的Forrester Wave(Translytical)中进入Strong Performers领域，领先于CockroachDB。
• Snowflake和Databricks依旧在领导者象限，位置稳定
• Redis连续三年，依旧保持在挑战者象限
• Cloudera也第一次进入了领导者象限，前两年均在远见者象限
• Couchbase也连续进入Niche Player象限
• MariaDB没有出现在今年的MQ当中，去年其在第三象限

十年Gartner数据库魔力象限

另外，笔者在2021和2018年也分别撰写过相关的解读，供参考：

• 2021 Gartner云数据库魔力象限正式发布
• Gartner云计算魔力象限（云计算IaaS MQ解读）

最后，根据之前的参评经验来看，其考察非常细致、考虑也非常全面，所以魔力象限在全球市场有非常强的参考价值。但是，因为其评估标准较高，尤其是对产品全球营收、市场全球化有非常高的要求。所有，也有部分非常有潜力的厂商都无法出现在该榜单中。例如，在中国市场影响力比较大OceanBase、TiDB、达梦等。另外，每年的Gartner测评流程也非常长，投入非常大，对于较小的厂商来说，可能会谨慎考虑是否参与该测评。

今天晚上熬夜不是为了看伊朗对美国的比赛，而是为了AWS re:Invent 2022大会的一个分享：凌晨00:30由AWS CEO Adam Selipsky的Keynote。re:Invent是AWS最盛大的年度大会，面向AWS的开发者、生态企业、客户等，会发布未来一段时间内最重要的产品与特性。

好了，已经很晚了，直奔主题，来看看关于数据库，AWS CEO都说了些什么。

Amazon Opensearch Serverless （Preview）

数据库与分析产品是整个Keynote的第一部分。首先提到的产品发布是 Opensearch Serverless，不过Adam并没有详细介绍该产品，而是强调，整个的数据分析产品体系全面实现了Serverless。

Amazon Aurora 与 Redshift的无缝数据集成

在介绍Integration部分的时候，Adam发布了Amazon Aurora 与 Redshift的无缝数据集成（Aurora zero-ETL integration with Redshift）。使用该特性：

• 可以实现几乎实时的数据集成，从而实现实时分析和机器学习能力
• 支持从多个Aurora数据库集成数据
• 自动更新且持续可用
• Serverless，无需维护基础设施

Redshift支持Spark功能GA

Adam介绍另一个Integration特性是：Redshift支持Spark。使用该特性，可以在EMR等平台上，直接运行Spark Queries对Redshift的数据进行计算，无需做任何的移动数据，支持多种语言（Java Python R等）。

其他

整体上，Keynote大致分成了几个部分：AWS整体价值概述、在线数据库、分析服务与产品、AI平台、集成产品与平台企业用户、权限、安全、合规管理、计算、容器、其他（供应链产品、生态体系产品、行业产品等）等。在其他部分也还有很多的产品发布，这里不一一详述，感兴趣的可以关注re:Invent官网：https://reinvent.awsevents.com 。

个人小结

整体上，数据库部分并没有特别大的发布。从平时的产品发布节奏来看，AWS在数据库方向的主要包括了Serverless（或者与Serverless生态的集成）、Graviton数据库实例的发布等。这次会上，CEO把在线数据和分析数据的集成单独拿出来讲，还是略感意外的。

当下信息技术的大背景依旧是数字化，数字化带来的海量数据以及海量计算能力的需求依旧是当前企业面临的主要挑战之一。一方面，AWS在持续的、一致的通过Serverless技术去改进数据处理的模式，通过Serverless的模式去降低价格成本以及维护成本。所以这一次，发布了Opensearch Serverless之后，整个分析产品体系都实现了Serverless的支持属于预料之中。 

另一方面，AWS也注意到ETL的困难已经在阻碍用户的数据价值发现，所以这次大会上提出了“A zero-ETL future”。同时，基于此理念（当然关系可能是反过来的），发布了“Aurora 与 Redshift无缝的数据集成”（Preview）、“Redshift支持Spark功能”（GA）。 

个人认为，数据流动困难确实是当下企业数据价值发现的一个大的绊脚石，不过，云厂商发布的集成方案，只能是在云厂商内部，虽然可以解决局部的问题，但是，对于实际用户来说，其数据分布可能更加广泛，可能分布在多个云厂商、或者本地IDC、或者云厂商的自建环境（EC2、ECS等）等。另外，数据存储与数据分析产品的发展都非常快，远不是局限于在某个云厂商的一方产品。总的来说，通过发布一些产品的内部集成能力依旧还是很难解决当前企业的数据流动问题的。就像CloudFormation和 Terraform的关系。

AWS re:Invent介绍

方便理解，re:Invent大会之于AWS相当于云栖大会之于阿里云，Oracle Open Wolrd之于Oracle。在这个会上，AWS会宣布最新的产品发布和特性。从这里也通常可以看到AWS宏观上的产品规划方向。另外，这是一个盛大线下的大会，在美国的Las Vegas举行，今年大会号称约有5万人在线下参加。

2018年线下参会回顾

2018年11月份的时候，在前东家的支持下，与斗佛一起去参加那一年的re:Invent。虽然2015年，之前也参加过OOW，也参与和组织多次云栖大会，不过还是被re:Invent震撼了。 

大会确实非常盛大，参加的开发者、生态企业非常多，即便是在Las Vegas，也没有一个酒店或者场所容纳这么多人，所以，大会在Vegas城区的数个大型酒店同时举行。不过，也因为酒店之间都是有一定距离的，所以，有时候需要听的session分布在不同的酒店，就会比较麻烦。当时的大会的主题是“Build”，可见，这是一个面向开发者的大会。除了主题分享，还有很多小型的workshop、培训认证、生态分享等，整体上，感觉对开发者比较友好，略微有趣，比较务实。另一个务实的体现，就是演讲内容很务实，CEO（当时是Andy Jassy）的Keynote也是非常的“干”，上来就讲技术、讲产品、讲产品特性，中间穿插几个客户案例，就结束了。这一点与国内区别非常大。 

好了，就这些吧，真的有点晚了。

在云时代，开发者与企业需要怎样的数据管理产品，一方面提升开发者的效率加速企业发展，另一方面又需要保障数据安全。NineData（www.ninedata.cloud）则是尝试在两者之间找到平衡，让开发者能够高效率且安全的完成企业内部的数据管理，发掘企业数据价值。

（本文根据作者在最近的产品分享整理而作）

百花齐放的数据时代

说“卷”并不合适，充分的竞争是可以给开发者/企业带来实惠的，当下的数字化也只是开始，潜力还非常巨大，所以，这里用了“百花齐放”来形容当下的数据时代。这里用两个“多”来具象化“百花齐放”这四个字。首先是云厂商多，这里简单罗列了一下，就有十六家厂商之多。另外，数据库也非常多，而且似乎还在变得更多。这里取了DB-Engines上10月份最新的数据，该网站十月份一共统计了397个数据库，这里列举了其中的15到20个，一部分是全球流行度最高的数据库，一部分是出现在DB-Engines榜单中的部分国产数据库。

数据管理的挑战与机遇

在这个百花齐放的数据时代，我们先看一下在数据管理场景下，有一些什么样的挑战。

在信息技术持续演进的过去几十年里，已经有一些传统的、成熟的数据管理软件和产品。这里列出来了一部分产品，包括Oracle Goldengate、Informatica、SharePlex等，我们自己也都比较熟悉，有些也用得很多。我们注意到，这些产于云时代之前的产品，并不能很好适应当下的环境。

第一，是权限管理非常困难。这些产品大部分是本地客户端，而企业内部的人非常多，开发人员少则是几十，多则是几百，要给每个人配置权限与账号，管理起来其实非常困难。另外，当用这些客户端工具的时候，企业内部操作审计也会非常困难。

第二，由于云厂商很多，数据会分布在不同的云厂商或者本地的IDC，此外，数据的种类也非常多，各种各样的数据库，导致数据流动也非常困难。而数据无法很流畅的流动起来，会导数据价值发现变得困难。

第三，使用这些工具产品的时候，对业务的稳定性挑战非常大。这些产品和工具，大多数都是由开发人员作为本地客户端使用，并且直连数据库，直接向数据库发送SQL请求，如果某一条SQL语句的性能不好，就可能让在线的数据库变慢甚至崩溃，以致于无法正常提供服务。

第四，这些产品通常都需要自己安装和部署，并维护其稳定性，在现在这个时代，每家企业都在非常快速和敏捷的发展，企业需要将最重要的研发资源都投入到自己最核心的业务上，而不希望在基础设施上花费过多的精力。所以，在这种情况下，这些软件的部署、维护以及稳定性的保障就会变得累赘。

NineData 全球领先的多云管理

这就是NineData（www.ninedata.cloud）产生的背景和原因，NineData要做的就是在这个多云时代，在这个数据库百花齐放的时代，构建全球领先的多云数据管理平台。

那么我们先来整体的看看来NineData，它有哪些产品能力，以及它在企业的数据架构中处于怎样的一个位置。一般来说，一家企业可能会同时使用多家云厂商、本地IDC等环境下的多种不同的数据库，在此之上，再构建企业自己的数据平台。

那么，通常数据都需要在多个环境之间互相流动，例如需要构建容灾、跨云迁移、构建只读实例等。另外，数据有时候还需要在多个业务系统之间流动，例如，因为在线数据需要向搜索平台流动，帮助企业构建实时搜索等；在线的数据还需要向数据仓库、大数据平台流动，帮助企业构建实时数据分析等。而数据在多个系统之间流动之后，为了保证数据质量，还需要对数据进行验证与对比。

在日常的开发与运营中，企业的开发人员、BI人员、业务运营人员、DBA等，可能因为在线数据分析、验证、问题排查等，都需要对数据进行读取与操作。

这就是我们今天发布的NineData平台向企业所提供的能力，以及通过上面的大图展现了他在企业数据架构中的位置。从功能模块上，NineData包括了四大块，第一个是SQL开发，第二是数据备份，第三是数据复制，第四是数据对比。

NineData SQL开发

首先，来看一下“SQL开发”产品。在企业内部，也有许多传统的开发工具和方案，例如DBeaver、Navicat、dbForge等，各个数据库通常也会提供一些附带的工具，例如MySQL Workbench这样的产品。另外呢，部分云厂商也会有一些自己产品提供给企业使用。但在实践中，我们遇到了一些问题。

第一，访问权限管理通常比较困难。因为这些客户端的工具都是由开发人员独立使用，那么，谁可以访问哪个数据库，有哪些权限，整个的管理就会非常困难。第二，使用这些工具的时候，开发人员需要直接连到数据库上来，那么如果编写的SQL语句性能不好，则可能会对生产环境的数据库产生重大影响，留下稳定性隐患。第三，数据安全日益重要的今天，这些产品，通常缺乏审计以及敏感数据保护等功能。另外，如果在企业内部，禁止研发人员使用这些产品，将所有的数据查询和数据处理的工作都交由DBA来执行的话，那么对整个企业的研发效率会有非常大的影响。

我们来看一下NineData的“SQL开发”产品，怎么解决这些问题。首先，他提供了完整的SQL窗口功能，可以帮助企业内部的所有开发人员去执行在线的数据查询，还支持完整的权限管理和审计日志等功能。这就让开发者便捷的访问在线数据的同时，又能保证安全。其次，它还支持“SQL任务”功能。通常为了保证生产环境的稳定，很多的数据库变更，需要在晚上或者凌晨去执行，如果由DBA晚上执行的话，一方面非常辛苦，另外，也非常容易出问题，那么，NineData的“SQL任务”就可以解决这些问题。使用该功能，研发人员或者DBA可以将自己的SQL变更定时的发布到生产环境，在这个发布的过程中，可以有多个审批的节点，由不同的人去把控风险。

此外，“SQL开发”模块还提供了表设计/表编辑功能，通过GUI式的交互，让你很简单的就可以去设计一个表，该功能支持的数据类型非常广泛，对每一个数据类型的选项也支持的非常完整。第三，是支持敏感数据的管理。如果你打开了某个数据库的敏感数据管理功能，它会自动去发现在这个实例中是不是有敏感数据，如果有的话，那么当用户去查询这个敏感数据的时候，默认的会对这些数据进行遮掩保护，用户需要额外的权限才能看到这些敏感数据。另外，支持的是列粒度的权限管理，当用户当他只需要查某一列的时候，可以单独申请某列的权限，另外所有的这些SQL查询功能，都支持很好的权限管理和审计，帮助企业更好的保护线上数据安全的同时，也让开发人员能够更高效的去完成日常业务开发。

简单的概括NineData SQL开发产品的常见使用场景如下。第一，在日常的业务开发中，用它去做SQL查询与开发。第二，生产数据的直接查询。另外，可以使用该功能去做生产变更的发布。NineData支持完整的权限管理、审计日志以及敏感数据保护等能力，可以非常好的保护企业的数据安全。

NineData数据备份和恢复

接下来，要介绍的是NineData的“数据备份和恢复”。

我们都说，现在是一个数据的时代，数据是企业最核心的资产。但是，数据安全却面临着诸多的挑战，并且，因为这些挑战对于单个企业来说并不频发，所以让这些安全挑战看起来很隐蔽。这些挑战包括了人为操作失误、应用程序错误、恶意软件攻击与勒索、硬件失败以及其他的一些不可抗力等，都会给数据安全带来风险。此外，相比于其他类型数据的备份，数据库的备份管理又更加复杂。备份数据库通常需要将数据文件和日志文件一起备份，很多时候配置文件也要一起备份，有时候，即便是没有正确备份配置文件，也会导致数据无法正常的恢复。另外，数据库的种类繁多，也增加了其备份的复杂性，如果想构建一个可以这个按时间点恢复的备份方案通常都比较复杂，想实现比较好的RPO和RTO保障并不容易。我们来看一下传统的数据库备份方案，看看有哪些优点和缺点，这里列了一部分备份产品和方案，在我们实践中发现，这些方案要么就是颗粒度太大了，要么太小了。例如Cohesity、Rubrik，所提供的备份能力粒度就比较大，通常只适合文件备份或者虚拟机备份等。又如数据库或者一些开源厂商所提供的单一的备份软件，如XtraBackup、mydumper、以及每个数据库自己提供的备份程序，他们的备份粒度又太小，他们通常只支持单个实例的备份。要构建一个企业级的备份方案，还有哪些挑战和问题？这里概括了几个点，第一，如果要构建一个完整的企业级备份方案，则需要做对应的机房建设、存储建设、网络建设等，而且对这些基础设施要求都很高，这带来的初始成本就非常高，而且规划建设的时间也非常长。第二，如果要构建一个异地数据灾备的话，那么前面所说的这些成本和时间的投入又要翻倍。所以，总的来说，需要投入的时间、人力和金钱成本都非常高。

我们看一下NineData如何解决这些问题。首先，它的配置非常简单，是一个SaaS化的服务，一分钟就可以完成整个的备份任务配置。第二，它可以达到RPO几乎等于零的效果。另外，它的备份性能也会非常高，10分钟可以完成100GB备份，可以满足绝大多数线上备份的诉求。另外我们还提供了超越业界所有的产品，并且非常实用的功能，就是对数据备份的实时查询。也就是说，在备份完成后，就立刻可以查询到备份中的数据，不需要去做恢复。这样就可以很好的去验证备份的有效性。第二，当数据发生故障的时候，也不需要花费非常长的时间，先去做数据恢复，就可以直接对历史的数据进行查询和恢复。

具体来说，该功能有如下模块。第一，它可以提供数据备份的能力，包括全量备份、单表备份、结构备份以及日志备份。第二，可以做对应的恢复，包括按时间点恢复，且RPO接近于零。另外，可以支持实时的备份数据查询，做快速的数据校验，也可以做简单的数据分析，这个是我们产品默认自带的功能，无需做任何的额外的配置。另外，它天然就支持全国数十个区域，可以选择将数据拷贝到异地区域实现跨区域的数据容灾。此外，还有失败告警、周期性备份等相关功能。

再简单的来看一下数据备份和恢复在企业内部有哪些典型的使用场景。首先，可以用它快速的去构建一个企业级备份的方案，具备高性能、按时间点恢复、快速查询验证等；第二，它可以帮助企业快速的构建一个跨区域的备份，帮企业满足等保等行业合规的需求。

NineData 数据复制

接下来，来看一下NineData的第三个产品：数据复制。

先看一下传统的数据复制方案，例如Oracle GoldenGate、Informatica、SharePlex等，另一个国内用户用得比较多的是自建开源的Canal，此外，各个云厂商也会提供一些数据复制和流动的产品或者方案。

这些方案大多需要自己搭建，安装配置成本通常都非常高。而且，由于数据库本身运行的SQL，包括DDL、DML等，非常多也非常复杂，如果长时间运行这些方案，都容易遇到各种各样的稳定性问题。一般，这些方案对于新的数据库或者新的版本支持都有一定的滞后，导致这些方案的长期稳定性比较差。云厂商也提供了一些方案，但大多数“宽进严出“。使用这些产品时，从其他云迁移到过来会比较容易，但是如果想将数据迁出去，则会遇到各种各样的限制甚至就直接不支持。

另外，同构数据和异构数据的适配通常都很困难。不同的数据库由于其特性差异大，架构原理也不一样，数据类型也不同，这些都导致异构数据复制困难，而这也就最终会阻碍企业去发现这些数据的价值。

NineData的数据复制产品，它是一个多云全托管的服务，支持阿里云、腾讯云等国内外主流的云厂商。另外，这是一个全托管服务，只需做一些简单的配置，就能拥有一个非常好的、长期稳定运行的数据复制链路。NineData同时支持同构和异构复制，不管是MySQL到MySQL，还是MySQL到可ClickHouse，都可以支持的非常好。另外，它的性能也非常好，TPS可以支持到10万，可以满足企业绝大多数在线的数据复制诉求。下面这个架构图，就是数据复制所具备的主要的产品能力，包括迁移时预检查、结构和对象迁移，全量数据迁移，增量数据迁移，以及在整个数据完成复制之后，支持对两端数据的对比和校验。

数据复制底层使用了基于增量日志解析的技术，可以让线数据复制的同时，减少对生产库性能的影响。NineData还支持库/表/字段三级映射，很好的实现异构场景下的数据复制。

企业最最常见的复制场景包括如下情况。最常见的应该是OLTP到OLAP以及大数据之间的数据流动，比如说数据仓库的构建、数据湖的构建、实时分析系统的构建等。第二个比较常见的是OLTP与OLTP数据库之间的数据流动。例如，需要构建一个双活的灾备，或者要从一个云厂商A迁移到云厂商B，或者需要构建一个用于只读的分析库等。

另外还有一比较常见的场景是OLTP数据到其他的应用系统的数据流动，例如到消息系统、搜索系统等，如果数据同步到消息系统，其他业务系统就可以很好的对这些数据再做新的分析和处理。

我们相信让数据更好的流动起来，就可以帮助企业更好的发现数据的价值。

NineData数据对比

最后，来看看NineData的数据对比。目前市面上有一些零散的数据对比产品，例如前面提到的Navicat、dbForge等，这些工具也支持数据对比，但是有如下的问题，首先，它是一个客户端的，它不能长时间的对在线的数据进行对比。第二，也因为是客户端的原因，它的性能也非常有限，通常只适合于小数据量的对比，比如适用于几千、几万的数据量。

但是，实际情况比较复杂。例如，通常每一家企业至少都有多套环境，包括开发测试环境、生产环境、预发环境、性能测试环境等，由于企业应用迭代速度很快，所以要保障多套环境下的数据结构一致就很难。第二，在海量的数据发生流动以后，数据不一致是非常常见的。第三，即便是在线实时同步的系统，不管是数据库的主备复制也好，或者是容灾复制也好，或者只读复制也好，在这些动态复制的过程中，由于各种原因，也会出现一些数据不一致。

这些场景都可以使用”NineData数据对比”去解。它有几个大的功能模块，包括结构对比、全数据量对比，另外它可以支持快速对比和周期性对比等。

该功能在完成了数据或者结构对比之后，可以快速的生成修复差异的DDL或DML语句，如果去目标库上执行这些SQL，就可以让两个数据库快速的达到一致的状态。NineData还会根据数据库本身的压力进行并发度的自动降级，如果数据库带来的压力太大，或者数据库本身的压力太大了的话，那么它就会自动降低对比的速度，从而优先保障数据库的稳定。

我们来看看使用数据对比的常见场景。包括，前面提到的多环境下的数据结构对比，以及在构建了多活多区域容灾的时候数据一致性校验，或者从IDC迁移到云上之后的数据一致性的对比。通过NineData的数据对比产品，可以更好的保障企业的数据质量。

这是一个百花齐放的时代，在这之中，NineData致力于构建于全球领先的多云数据管理平台。现在大家就可以登录NineData官网 www.ninedata.cloud 体验完整的产品功能

关于作者

周振兴，是NineData的联合创始人，致力于解决云时代的数据管理挑战。周振兴是数据库领域的一名老兵了，是Oracle ACE（MySQL方向），也是《高性能MySQL》第三、四版的译者。2009年，加入了阿里数据库团队，在这个团队供职12年，是阿里数据库架构演进的核心人员，从早期的去IOE，再到全面分布式支持历届的双十一。之后，则在阿里云上将集团的数据库技术全面云化，服务更多云端客户。

更新@2023年1月

应部分读者要求，制作了一个《高性能MySQL 第四版》主题页：链接。主题页中包含了该书籍的适合读者、如何阅读该书籍、该书籍中涉及的链接、以及部分来自读者的勘误等，供参考：高性能MySQL。

---

十年经典再更新

十年前，当时Ningoo找到我们翻译第三版时（参考），还是一个刚刚进入数据库领域的小兵。十年后，当初的译者们，都已经在各个公司的数据库方向成为中坚力量。

时隔十年，《高性能MySQL》再次出版，这是该系列的第四个版本。过去十年，《高性能MySQL 第三版》已经成为除了文档之外，MySQL相关开发者、DBA等从业者的必读书目，在豆瓣上也收到了9.3分的好评。

MySQL在中国的这十年

过去十年也是中国MySQL快速发展的十年。在2022年，CSDN的中国开发者调查报告中的数据，在中国，有73%的开发者都在使用MySQL，稳居第一名，且遥遥领先其他数据库。一方面是中国互联网在过去十年的快速发展背后，需要海量的、低成本的数据库存储方案，另一方面，更重要的，随着中国开发者、DBA能力增强，从原来的用好开源，逐步成长为开源背后的重要的贡献力量。无论是，阿里、腾讯、华为、百度、去哪儿等公司，都在通过各种方式，一方面输出自己的最佳实践，另一方面也在向MySQL代码库贡献自己的力量。

随着，中国厂商在MySQL技术使用和商业上的深入，以阿里云、腾讯云、华为云为代表的中国技术厂商已经成为MySQL社区重要力量：

• 在2018年，阿里云数据库RDS团队，因为多源复制、FlashBack等功能获得了MySQL Community Awards，彭立勋作为代表在Percona Live接受颁奖：参考
• 2018年，在5.7.17版本，由翟卫祥贡献的关于Group Commit和GTID的优化：参考；2021年，在8.0.24版本中，由翟卫祥修复的关于InnoDB Recovery阶段性能问题：参考。除此之外，翟卫祥其实是比较频繁的出现在MySQL Release Note的人。也因为这些贡献，翟卫祥也在2019年也获得了MySQL Community Contributor of the Year的奖项：参考。
• 2019年，腾讯游戏CROS DBA团队的陈福荣（Vin Chen）、梁飞龙（Felix Liang）也获得MySQL Community Contributor Award：参考。
• 2022年，彭祥在今年成为MariaDB Foundation的Board Members，他也是阿里云RDS业务的负责人。
• 2022年7月，在最新的8.0.30版本中，来自腾讯CDB团队的Yuxiang Jiang和Zhou Xinjing修复了部分关于InnoDB、PS相关的Bug：参考。
• 另外，在MySQL Bug系统上，也经常能够看到国内厂商的身影，主要是阿里云和腾讯。

在国内社区，诸如丁奇、彭立勋、周彦伟、杨建荣、韩锋、杨奇龙、叶金荣、沃趣科技、盖国强、何登成等都非常活跃，通过ACMUG、DBAplus、墨天轮等平台推广数据库的最佳实践。另外，国内各个大厂也都还有隐藏着非常多的“扫地僧”级别的高手，抛头露面比较少，诸如ba0tiao、江神、Jimmy（这里无法一一列举）也是中国MySQL社区非常重要力量。

MySQL凭借着其强大的影响力，也影响着一系列的产品的发展。在云时代，MySQL依旧是主角。在2014年AWS推出的Aurora、2017年阿里云推出的PolarDB、2018年腾讯云发布CynosDB（TDSQL-C前身）都首先选择了兼容MySQL。而众多新的数据库，诸如OceanBase、TiDB、PolarDB-X、ClickHouse、AnalyticDB等都或者选择兼容MySQL或者使用MySQL类似的SQL方言。而各个云厂商，凭借着MySQL开放、开源，基于其构建的RDS、或者云原生数据库都赚的盆满钵满，通常，都能够占到其数据库收入的50%以上。这也从经济基础上，保障了各个云厂商依旧会坚定不易的在MySQL方向投入大量人力，推进MySQL的发展。到目前为止，MySQL数据库也成为了“开源技术”和“云厂商”之间，在技术利益非常庞大的时候，依旧能够较为“和谐”相处的案例之一。

兼容MySQL的分布式数据库

全球的MySQL数量约为800万个，大量的运行场景已经催生更加垂直和高要求的产品。兼容MySQL的分布式数据库就是其最重要的一个方向。从需求上来说，随着数据的快速增长，在越来越多的场景下，MySQL单机架构已经无法满足需求，分布式数据库在过去10年也在快速发展。2010年，阳振坤在淘宝内部开始研发OceanBase，自2015年后，开始逐步在外部探索商业化，同时兼容MySQL和Oracle；TiDB于2015年正式发布，兼容MySQL协议；2020年，在云栖大会上，阿里云数据库负责人李飞飞也宣布，DRDS正式升级为PolarDB-X，并于2021年正式开源，也是兼容MySQL协议。2018年，ShardingSphere发布（前身为Sharding-JDBC），也是兼容MySQL的。

在中国当下，分布式数据库的竞争是异常激烈。在今年（2022年）的4月份，TiDB发布了6.0版本，将TiFlash也正式开源，之后也很快上线TiDB Cloud，上线了阿里云心选商城。OceanBase也于今年的8月发布了4.0版本，单机部署最小支持4核8G；分析能力实现了由全场景向量化能力覆盖；OceanBase Cloud也会很快上线。另外，PolarDB-X也在持续的增强，发布包括了与MySQL兼容性比较好的AUTO_INCREMENT、数据热点诊断、冷热数据存储分离、Flashback Query等功能。另外，ShardingSphere、TDSQL等也在快速发展。

另外，在今年9月，TiDB和OceanBase都不约而同的在美国硅谷开始做产品推广，这个竞争已经逐步从国内延伸到了海外。这也是该行业快速发展与繁荣的体现。

自此，中国的数据库已经逐步从最早的用好开源、贡献开源，慢慢走向自主研发、独立品牌的模式，也从国内竞争开始走向更大的国际市场，这是中国数据库在商业模式、技术能力、生态建设都更加强大的体现。

新的版本，新的技术

MySQL 5.1是十年前的主流版本，期间经历了5.5、5.6、5.7，到现在8.0逐步成为当前的主流版本。在最新的“第四版”发布时，MySQL最新的版本为8.0.20，所以，书中很多案例与测试也都在该版本中经过了测试与验证。

这次出版的《高性能MySQL 第四版》则新增了过去十年MySQL各个新版本特性。新的版本背后代表的是新的技术。例如，从5.6开始引入、5.7和8.0版本中逐步成熟的GTID技术，大大提高了MySQL复制时的数据一致性、以及可运维性，也使得MySQL在整个数据流生态中，变得更加易用；随着，NoSQL的流行以及部分应用或者模块中Schema Free设计的出现，MySQL在最近的版本中，一直在不断增强对JSON的支持，包括操作JSON函数支持、性能优化、表达式函数支持等，使得在MySQL中也可以非常自由、高效的管理JSON数据。

性能管理一直是该书目的重点部分，最新版本的MySQL也在不断的完善Performance Schema（简称“PS”），帮助用户更加系统的进行性能管理与优化。在第四版中新增的第三章则系统的介绍了PS，可以帮助读者系统的了解如何通过PS查看数据库/InnoDB内部的运行指标，从而观测性能并针对性的进行优化。

云数据库已经成为数据库领域最重要的方向。本书也增加了关于云数据库的篇幅，并以AWS Aurora、谷歌云数据库、云主机自建数据库为代表，介绍了当前云数据库的使用、能力以及限制等。随着云计算、IoT、互联网等技术发展，数据量也一直在快速增长，本书也增加了关于如果扩展MySQL的章节与篇幅，包括通过只读节点进行的读扩展，以及如何通过拆分的方式进行写扩展等。

另外，本书另一个重要特点是做了大量删减，全书也从原来的第三版约800页精简到约350页：

删除了所有的MyISAM引擎相关的内容。MyISAM引擎是最早版本MySQL的原生引擎，但由于其架构缺陷、不支持事务、性能等原因，自8.0版本开始彻底被InnoDB替换。 

删除了大量关于如何配置MySQL的内容。随着时间的推移，现在的MySQL文档已经非常详尽的描述了这部分操作。本书则侧重于原理、使用、最佳实践等。  

删除或大大简化了诸如分区表、调度事件、全文索引、Query Cache等特性的介绍。虽然，在十年前这些都还算是MySQL的“高级特性”,但现在已经为大家所熟悉，而且文档已经了非常详细的描述，本书则不再介绍这些内容。

当然，依旧保留了最重要的部分，包括MySQL架构与基础原理、可靠性管理、SQL优化、索引设计与优化、硬件与软件适配优化、表结构设计规范与原理、复制技术、备份与恢复、垂直与水平扩展、云数据库等。

整体上，依旧非常推荐大家购买与阅读。本书，在翻译出版过程中也得到了很多数据库领域朋友的支持，包括沃趣科技陈栋、云和恩墨盖国强、OceanBase的阳振坤、周彦伟等，尤其是，阿里云数据库负责人、ACM/IEEE Fellow李飞飞 特意拨冗指导并撰写推荐序言，这里引用如下：

随着互联网行业以及云计算产业的高速发展， MySQL成为世界范围内以及中国数据库领域最流行的开源数据库。在几乎所有大型互联网业务场景中， MySQL都是业务架构的核心组件之一。广泛的应用也推动了MySQL在过去十年的高速发展，MySQL社区相继推出了5.6、5.7、8.0版本，从性能、可扩展性、安全性、稳定性、可维护性、易用性等维度都有了非常大的发展。《高性能MySQL 第三版》是2012年发布的，最新版本的《高性能MySQL 第四版》在上一版的内容上延续了之前的经典内容，包括架构设计、优化、高可用等内容，同时新增了云数据库、扩展性等过去10年发展的相关内容，另外，也增加MySQL过去10年里的最新版本包括5.7、8.0版本的最新的特性和内容。

MySQL作为当下最流行的开源数据库，本书从实践的角度涵盖了数据库系统的架构设计、锁、性能管理、高可用等内容，除了作为MySQL的参考书之外，也可以作为数据库系统原理和设计的一个实现参考。随着云数据库的流行，这本书的最新版也做了相应的调整，例如，将数据库的安装、配置、监控搭建等基础操作内容(云数据库封装并提供了大部分这些能力)做了大幅度的缩减。因此，本书也非常适合面向云数据库系统开发者的一本MySQL参考书籍。如本书的名字所述，本书在内核设计、性能优化方面，依旧是着墨最多的部分，深入介绍了锁管理、并发控制、Performance Schema使用、索引优化等内核机制，可以帮助企业的DBA、或者想深入了解MySQL优化的开发者，以及云数据库开发者更高效的使用和拓展MySQL。

本书的译者是云数据库领域和MySQL数据库的资深专家，有着很强的技术能力和行业实践以及业务洞察，同时也具备非常出色的业务架构设计和商业化经验。在深入理解原著的基础上，结合自己的洞察和经验提供了出色的专业化中文版本，是MySQL领域不可多得的一本必读书目。

Shadowserver Foundation在5月31日发布了一份全网的MySQL扫描报告，共发现了暴露在公网的360万个MySQL实例。因为这份报告基数够大，而且信息也非常完整，从数据库专业的角度来看，里面是有很多非常有意思，且可以量化的数据和结论的。之前网上的一些分析都是基于安全角度来分析，这里我们一起再看看这份报告里面隐含的一些数据库信息吧。

另外，这里的“暴露在公网”，是指其端口在公网可以被访问且响应握手信息，并不是可以被登录，并没有什么安全隐患。原报告的文章链接可以在文章结尾处查看。

数据说明

该数据由Shadowserver的SCANNING PROJECT收集，总计扫描到537.8万个打开的3306端口，其中IPv4协议的395.7万个，IPv6协议142.1万个。这些端口中反馈了握手信息的共360万个，其中IPv4协议的228万个，IPv6协议134.4万。

返回握手信息的360万实例，因为握手信息包含了版本等信息，加上Shadowserver的地域等信息，就构成了一份较为完整的MySQL实例版本和实例分布数据。

Shadowserver并没有公布完整的数据详细信息，但依旧公布了多个维度的数据供分析。

8.0 GA已经四年，但5.7依旧是主流

以IPv4 Top 10的版本来看，当前5.7版本占比最大，其次为5.6和8.0版本。另外，MariaDB占比14%，更具体的：

• MySQL 8.0 GA日期为2018年04月，占比为8%
• MySQL 5.7 GA日期为2015年10月，占比为46.7%
• MySQL 5.6 GA日期为2013年02月，占比为30%
• MariaDB版本占比为14%，包括了MariaDB 5.5占比8.1%，其10.1版本占比6%

可以看到，MySQL 5.7依旧为当前最主流的版本，根据MySQL官方的规划，该版本可能在明年的10月就会停止对其的扩展支持，可能就不再更新版本。与此同时，MySQL官方还可能会在今年推出新的大版本（可能是9.0或者8.1之类的），加上5.7的维护周期接近尾声，会较为大量的用户升级到新版本。

全球共有800万MySQL实例在运行

根据一些公开数据和部分经验数据，这里对全球MySQL运行实例个数做一个预测。在这份报告中，共探测到约538万开放的3306端口，其中约360万返回了握手信息。那么，全球一共有多少MySQL在运行呢? 这里基于以下信息做一个猜测：

• 根据帕累托法则，即2/8原则，约仅有20%的因素影响80%的结果
• 诸如Google、Amazon、微软、阿里巴巴、腾讯、字节跳动等大型企业保有大量实例，且不可以被扫描
• 还会有大量实例运行在AWS、Azure、阿里云、GCP等云环境的VPC之中，如果没有开启公网IP，通常也无法被扫描到，这部分根据一些经验数据，预计为200万个
• 根据IDC数据，全球服务器2021年出货量为1350万台

那么，扫描到538万再加上200万，则有约738万个”闲散”实例。根据2/8原则，诸如Google、Amazon、阿里巴巴等这些大型企业(非云部分)中依旧可能保有着20%的实例（738万为80%部分），也就是约为184.5万个实例。那么预计：全球整体MySQL实例数量可能在922万这样的数量级。

另外，我们再从全球服务器出货量角度做一个验证。根据IDC数据，2021年全球服务器出货量约为1350万台，这里假设（该假设基于一些历史的经验）10台服务器对应一个数据库实例，那么2021年服务器出货量就对应了135万个实例，按照服务器平均5年折旧计算，总保有则约为675万个实例，这里与922万有一定的偏差。折中取这两个数据的平均值，所以这里预测：全球MySQL实例数在800万左右。当然，这只是一个超大颗粒度的、不可验证的预测，如果有更好的预测模型或者数据支持，欢迎回复公众号讨论。

MariaDB在某些细分市场份额很大

从这份数据来看，MariaDB是拿下了非常大的市场的。从IPv4 top 10版本统计信息来看，MariaDB占比为14.3%；如果，单从IPv6的统计数据来看，MariaDB占比为86.2%，实例数量超110万。

这里在IPv6环境中，部署量最大的版本为：5.5.5-10.5.12-mariadb-cll-lve，这是一个cPanel在Lightweight Virtual Environment的发行版本，而对应的MariaDB 10.5.12版本为2021年8月发布。从这个点看到，MariaDB是获得了更多的开源社区的信任，作为其发行版的默认数据库版本。甚至在一些细分的场景中，MariaDB甚至可以说可能成为了主流。

但，另一方面，根据在中国的实际感受来看，MariaDB的市场现状并没有以上数据展示的那么乐观，原因如下：

• 一是MySQL品牌依旧非常强大，虽然安装的MariaDB，但是实际使用的客户端依旧可能是mysql命令行，所以，用户依旧当做MySQL来使用。
• 另外，目前，大型企业全面使用MariaDB支撑核心业务的公司还比较少，大部分依旧是使用MySQL，并基于MySQL去进行优化，而不是MariaDB。

当然，从这个数据角度来看，MariaDB的这个部署量依旧会给其带来很多优势：

• 提升用户认知基础，虽然命令行依旧使用mysql，但是登录后依旧会看到MariaDB版本号信息和功能
• 产品会在各种环境中被使用，对其整体的稳定性会有较大的保障
• 相比MySQL，MariaDB已经获得更多Linux发行版的信任，这可能是进一步获得扩大市场的最重要的机会点之一

49%的实例启用了TLS/SSL加密

从所有IPv4环境的实例数据来看，有49%启用了TLS/SSL加密。因为MySQL 5.7之后的版本，都已经默认开启了传输加密，这与前面的MySQL 5.7占比数据是基本吻合的，大部分用户在使用5.7或8.0的时候，都会使用其默认自带的加密能力。所以，你的实例开启了传输加密吗？延伸阅读：

• 开启TLS传输加密对数据库性能的影响
• 是时候开启数据库的加密传输了

中国的MySQL实例在全球占比15.8%

在这份报告中，从IPv4的数据中看到，中国MySQL实例数占比为15.8%（大陆地区约为13%，香港地区约为2.8%），仅次于美国的32.5%。其次是波兰、德国、法国、新加坡等地。另外，根据IDC的报告中国服务器出货量占全球比率约为25.3%（2021年，从销售额角度），所以，中国数据库的实际部署量可能更大。

IPv6在全球普及率都不高，中国更低

从整体数据来看，有握手反馈的扫描中，IPv4的3306共扫描到2,279,908个，IPv6共1,343,993个，在全球角度上，运行在IPv6上的MySQL已经达到了37%。但是，这个数据在中国，仅有0.1%。虽然，数据库部署并不适合作为IPv6和IPv4的对比，但作为一个参考，可以看到在全球范围IPv6已经比较高了，但是在中国普及率还非常低。

从这份数据来看，IPv6较高的国家有：美国、荷兰、新加坡、德国、英国等。

这份数据的一些限制

• 因为报告是通过端口扫描获得的信息，所以各个大公司自己内部的服务器都是不在其中的。所以，实际MySQL装机量应该远大于这个量。另外，大公司企业数据库情况可能与报告有一定的偏差。例如，通常大公司环境中数据库版本会比较统一，而不会简单的使用最新版本。
• 报告中的数据可以看到MariaDB的部署量比想象的要大。猜测的原因可能是，很多Linux发行版本中自带的仓库使用的是MariaDB数据库，这让MariaDB的装机量比想象的更大。
• 另外，报告没有公布所有的数据，例如版本数据，只有Top 10的版本，占整体IPv4的比率约为26%，还不是一个完整的数据，可能与整体数据会有一些偏差

其他补充说明

• MariaDB的握手阶段提供的版本信息与实例中的信息有一些不同，所以会呈现出比较多的是”5.5.5-10.5.12-mariadb-cll-lve”这样的版本号，其中10.5.12才是MariaDB正确的版本号；”cll”应该是代表有cPanel编译提供的发行版(参考)；”lve”则可能是”Lightweight Virtual Environment”的缩写。
• Shadowserver Foundation是什么？“Shadowserver是全球领先的恶意活动调查、互联网安全报告的公益组织，Shadowserver维护着世界上最大的安全信息存储库之一，它存储了数以万亿计的历史恶意网络连接，同时Shadowserver每天扫描整个互联网超过50种协议暴露情况，用于查找可能用于攻击利用的配置错误或存在恶意行为的系统，Shadowserver拥有超过20个监测节点。”
• Shadowserver还扫描了MongoDB、Redis、SQL Server的情况。MongoDB约为10万个（101338，参考）、Redis约为2.5万（参考）、SQL Server约为8.5万（参考）。如果说，MySQL在很多Linux环境中可能默认安装，但是这几个数据库一般是不会被默认安装的。
• 报告中IPv6协议下的MySQL实例数据与实际感受差距非常大，例如在IPv6版本下，MariaDB占比约为85%（超100万实例）。在IPv6实例最多的国家是美国、荷兰、新加坡等来看，这与服务器出货量相关数据匹配度非常低。所以，有几种可能：一个是MariaDB在某个细分的场景下有非常大的优势，在早期对IPv6支持更好，所以在某些对IPv6有强制要求的地区和国家有更好的市场。
• 再次声明这里的“暴露”在公网，并不是说这些实例不安全，因为这里的探测不能，也没有连接上数据库，而是在连接之前的握手数据交换阶段。

原始报告链接

• https://www.shadowserver.org/news/over-3-6m-exposed-mysql-servers-on-ipv4-and-ipv6/