作者：

大数据模型

对制造业、银行业、通讯业了解多一点，关心专注国产数据库技术布道以及数据资产建设的应用实践。

导读

随着 MySQL 8.0 的发布和即将到来的 5.7 版本的停止支持，许多 MySQL 用户正面临升级和转型的抉择。本文为 TiDB 社区用户撰写，以一名开发者的视角，深入探讨和比较了 TiDB 和 MySQL 的差异。希望通过本文，能为读者在架构选型方面提供一些帮助和指导 。

TiDB 在墨天轮国产数据库排行榜中长年位列前茅，社区活跃度高且人气旺盛。那么 TiDB 使用场景相似产品中，有哪些比较优秀呢？我认为其中一个是 MySQL——毕竟在中国，MySQL 早已深入人心，并且工程师们能够轻松地运用它。

TIDB 与 MySQL 的对比

有些人直接将 TiDB 称为"大号的 MySQL"，但实际情况并非如此。为了使工程师们能够像使用 MySQL 一样使用 TiDB，TiDB 在接口层进行了大量的改进。它在语法、表名、引用甚至元数据等方面尽量与 MySQL 保持一致，但是实际执行的每个语句背后都有不同的数据流程和服务流向。因此，尽管在表面上它们相似，但其背后的数据处理和服务机制是不同的。

类型方面 ，MySQL 是纯粹单机式数据库，TiDB 则是分布式数据库。TiDB 能够方便自由地增加节点来扩展存算能力，而 MySQL 则需要通过定向策略，如中间件路由或读写分离等方式来增加节点以提升性能，这使得 MySQL 的扩展性相对受限且相对僵化。

引擎方面 ，MySQL 拥有多个引擎选项，如 MyISAM、InnoDB、Memory 等，并且可以通过插件支持更多的引擎，如 RocksDB 和 HandlerSocket 等。而 TiDB 虽然只有两个引擎选项，但却能够应对各种应用场景的需求。

架构方面 ， MySQL 是偏紧密耦合 ，分为接口层、服务层、存储层三个层次。接口层负责请求处理、授权认证和安全性，服务层负责查询解析、分析、优化、缓存和系统内置函数，存储层负责数据的存储和处理，所有这些组件都在一个服务进程中统一运行。 而 TiDB 采用松散耦合的架构，将数据库的关键组件进行抽象，并根据其分布式特性划分为计算层、存储层和协调层。

● TiDB 计算层类似 MySQL 的接口层，负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过协调层找到存储层数据的位置。它与存储层进行交互以获取数据，并最终返回结果。

● TiDB 的存储层负责数据的存储，其存储容量没有上限。通常情况下，存储层会为同一份数据维护 3 个副本；以满足高并发需求。协调层会对存储层中的数据进行负载均衡的处理。

● TiDB 的协调层是集群的管理模块，其主要工作包括三个方面：管理集群的元信息、调度和负载均衡存储层的数据，以及分配全局唯一且递增的事务 ID。

数据处理技术上 ，MySQL 是 B+树 的组织存储结构，B+树适合读多写少，如果写多了，写的影响动作主要是插入、删除，会导致全局的平衡树下面的页频繁分裂或者合并，直接影响性能，影响读放大。 TiDB 是 LSM 树的组织存储结构，擅长写多读少，如果读多了，在内存扫描不到数据，就会去硬盘里面去寻找无序的 sst 文件，所以数据越多越大就会读放大。

处理存储上 ，MySQL 类似微内核，微内核架构由核心服务和插件模块组成， 核心服务负责请求后处理机制流程并进行优化，插件模块主要用来放置 置处理存储的引擎，引擎决定性能上限 ， 微内核的插件式对开发者友好，可以自由扩展，所以 MySQL 派生了 infobright、MyRocks 等第三方相关引擎，TiDB 的核心服务分散在 TiDB 模块和 PD 模块里面，两者协同工作构成请求解析、处理、优化及其它服务功能 ， TiKV 模块和 TiFlash 模块则是引擎。无论是顺序读写还是随机读写， 核心服务协同背端的引擎 工作串成整个数据全链条过程，MySQL 是在单机单进程的内部去完成这个过程的，而 TiDB 是分布式多进程完成这个过程的。

产品方面 ，MySQL 默认使用 InnoDB 引擎，擅长处理 OLTP 的业务场景。同时，MySQL 还支持插件组装各种引擎，使其成为一个通用型的数据库产品，适用于各种业务场景。而 TiDB 默认采用悲观事务的方式，同样专注于 OLTP，也是一个通用型的数据库产品。然而，这两者之间存在一些差异。由于 MySQL 是单机型结构，如果需要进行扩展，只能通过数据库中间件路由的方式进行划分。而如果数据已满，就需要停机或停服，重新进行数据的分割。

TiDB 具有对业务的无侵入性，且扩展非常简单。在其发展至今，安装和维护方面已经非常成熟。通过 TiUP 工具，可以轻松进行分布式集群的组装和维护操作，并且支持在线升级和无缝迁移。这使得使用 TiDB 的过程更加便捷和高效，使用户能够更好地管理和运维他们的分布式数据库系统。

综上所述，TiDB 与 MySQL 属于不同类型的数据产品，并不能直接进行对比。然而，从数据库的特性和市场趋势的角度来看，它们可以有一些维度上的对比指标。事实上，TiDB 致力于向 MySQL 学习，并且还聘请了 InnoDB 的核心开发工程师，致力于调整 TiDB 的底盘，使其在内部和外部都更像 MySQL。

同类竞争产品

TiDB 是一款 分布式数据库产品 ，它以分布式为标识并能基于线下安装，在国内外都有类似的产品。那么 TiDB 与其他产品有什么不同？参照数据库处理的流程，我将从任务开始到任务结束来详述。

1. 用户发起请求：数据库客户端向指定的数据库集群发起请求。

2. 目标数据库响应：数据库集群的指定节点响应用户的请求。

3. 两者建立会话：数据库集群其中一个节点与客户端产生会话。

4. 对象请求解析 ：数据库对接收到的请求进行语法检查、对象解析，并将其转换为对应的关系代数结构，然后进行计划任务优化。

5. 调度并且执行：寻找最合适的副本，根据优先级进行，是内存、缓存、数据快照、存储等等。

6. 监测任务状态：数据库监测执行中任务的状态。

7. 返回数据结果：数据库服务端将执行结果返回给数据库客户端 。

上述环节中，最关键的是第 2 步、第 4 步和第 5 步。

第 2 步是 哪一个节点响应数据库客户的请求，分布式数据库有两种系统架构，一种是中心化架构【masterslave】，一种是去中心化架构。中心化架构的负色职责分清，负责干活、负责指挥、负责接待用户，而去中心化架构则是每个节点角色平等，对待客户的请求，其中的一个节点会瞬间切换成负责接待，剩余的节点根据情况转化执行。

TiDB 在这里采用中心化的架构，节点角色之间的职责更加清晰，分工更加明确。

第 4 步和第 5 步是数据计算和数据存储的关键步骤，TiDB 在这里做了深度的松散解耦，数据计算用 TiDB，数据存储用 TiKV，两者是真正意义上的存算分离，要增加存储容量，可以增加没有 CPU 的硬盘服务器，要增加计算能力，可以增加没有硬盘的服务器。关于分布式的功能和作用则集中在一个 PD 的模块上。

采用集中式的分布式架构的产品则采用了去中心架构，而且计算和存储高度耦合，又称为单机式的分布式架构。

TiDB 比起同类产品在架构上更加高度松散耦合，与云计算技术更加紧密协作，珠联璧合。

TiDB VS MySQL

如果 TiDB 要做大做强，必须要撼动广大开发人员的工作使用习惯。大部分开发人员已经十分熟悉并广泛使用 MySQL，无论是在 TP 应用还是 AP 应用中。不论性能如何，他们首先会选择 MySQL 来开发业务代码。这也意味着 MySQL 经常被用作 HTAP 数据库。接下来，我将使用 CH-benchmark 来对 TiDB 6.0 和 MySQL 8.0 进行一项测试。

TPC-CH 由未经修改的 TPC-C 模型和事务、以及 TPC-H 查询的改编版本构成，TPC-CH 保持所有 TPC-C 实体和关系完全不变 ，并集成了 TPC-H 模型中的 SUPPLIER、REGION 和 NATION 表。这些表在 TPC-H 查询中频繁使用，并允许以非侵入的方式集成到 TPC-C 模型中。SUPPLIER 包含固定数量（10,000 条）的条目。因此，STOCK 中的一条记录可以通过 STOCK.S I ID × STOCK.S W ID mod 10, 000 = SUPPLIER.SU SUPPKEY 与其唯一的供应商（SUPPLIER 表中对应记录）关联起来。TPC-C 中的原始 CUSTOMER 表不包含引用自 NATION 表的外键。我们并没有改变原始模型，从而保持了与现有 TPC-C 的兼容性，所以外键是从字段 C STATE 的第一个字符开始计算的。TPC-C 规定第一个字符可以有 62 个不同的值（即大写字母、小写字母、数字），因此我们选择了 62 个国家来填充 NATION。根据 TPC-H 规范，主键 N NATIONKEY 是一个标识符。它的值被规定，从而使得与这些值相关联的 ASCII 值是一个字母或数字,即 N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97. 122]。因此，不需要额外的计算来跳过 ASCII 码中数字、大写字母和小写字母之间的间隔。不支持从字符转换到 ASCII 码的数据库系统可能会偏离 TPC-H 模式，使用单个字符作为 NATION 的主键。REGION 包含国家的五个地区。新表之间的关系使用简单的外键字段来建模：NATION.N REGIONKEY 和 SUPPLIER.SU NATIONKEY。

在 CH-Benchmark 中结合了 TPC-C 和 TPC-H 两种基准 ，它把原来 TPC-C 中的 9 个表和 TPC-H 中的 8 个表修改合并成了 12 个表，并将两者的伸缩模型也统一起来（Scaling TPC-H by the same factors of TPC-C）。

测试环境

硬件配置

测试配置

生成数据

在我的实验中，我使用了 TiDB Bench 对数据进行了压测，生成这些数据的工具是 CH-benchmark。

安装 CH-benchmark

https://github.com/DASLab-IDA/CH-benchmark  

​
​
-rwxr-xr-x. 1 root root 1007440 Mar 29 16:13 chBenchmark
-rw-r--r--. 1 root root 12745 Mar 3 2022 chBenchmark.cpp
-rw-r--r--. 1 root root 194096 Mar 29 16:13 chBenchmark.o
-rw-r--r--. 1 root root 561 Mar 3 2022 LICENSE
-rw-r--r--. 1 root root 1167 Mar 3 2022 Makefile
-rw-r--r--. 1 root root 2650 Mar 3 2022 README.md
drwxr-xr-x. 3 root root 4096 Mar 29 16:13 src
[root@hdp1 CH-benchmark-main]# make
​
​
运行make之后会就对当天的文件进行编译，生成chBenchmark 执行命令
​
chBenchmark命令如下
Create initial database as CSV files:

chBenchmark  
-csv  
-wh   
-pa   

​

example: chBenchmark -csv -wh 50 -pa /path/to/any/directory  
  

生成数据如下,生成一个warehouse的数据
​
chBenchmark -csv -wh 1 -pa /tmp/chBenchmark1

4.1 建表语句

CREATE TABLE `customer` (  

c_id int NOT NULL,
c_d_id int NOT NULL,
c_w_id int NOT NULL,
c_first varchar(16) DEFAULT NULL,
c_middle char(2) DEFAULT NULL,
c_last varchar(16) DEFAULT NULL,
c_street_1 varchar(20) DEFAULT NULL,
c_street_2 varchar(20) DEFAULT NULL,
c_city varchar(20) DEFAULT NULL,
c_state char(2) DEFAULT NULL,
c_zip char(9) DEFAULT NULL,
c_phone char(16) DEFAULT NULL,
c_since datetime DEFAULT NULL,
c_credit char(2) DEFAULT NULL,
c_credit_lim decimal(12,2) DEFAULT NULL,
c_discount decimal(4,4) DEFAULT NULL,
c_balance decimal(12,2) DEFAULT NULL,
c_ytd_payment decimal(12,2) DEFAULT NULL,
c_payment_cnt int DEFAULT NULL,
c_delivery_cnt int DEFAULT NULL,
c_data varchar(500) DEFAULT NULL,
PRIMARY KEY (c_w_id,c_d_id,c_id),
KEY idx_customer (c_w_id,c_d_id,c_last,c_first)
);
​
​
CREATE TABLE district (
d_id int NOT NULL,
d_w_id int NOT NULL,
d_name varchar(10) DEFAULT NULL,
d_street_1 varchar(20) DEFAULT NULL,
d_street_2 varchar(20) DEFAULT NULL,
d_city varchar(20) DEFAULT NULL,
d_state char(2) DEFAULT NULL,
d_zip char(9) DEFAULT NULL,
d_tax decimal(4,4) DEFAULT NULL,
d_ytd decimal(12,2) DEFAULT NULL,
d_next_o_id int DEFAULT NULL,
PRIMARY KEY (d_w_id,d_id)
);
​
​
CREATE TABLE history (
h_c_id int NOT NULL,
h_c_d_id int NOT NULL,
h_c_w_id int NOT NULL,
h_d_id int NOT NULL,
h_w_id int NOT NULL,
h_date datetime DEFAULT NULL,
h_amount decimal(6,2) DEFAULT NULL,
h_data varchar(24) DEFAULT NULL,
KEY idx_h_w_id (h_w_id),
KEY idx_h_c_w_id (h_c_w_id)
);
​
​
CREATE TABLE item (
i_id int NOT NULL,
i_im_id int DEFAULT NULL,
i_name varchar(24) DEFAULT NULL,
i_price decimal(5,2) DEFAULT NULL,
i_data varchar(50) DEFAULT NULL,
PRIMARY KEY (i_id)
);
​
CREATE TABLE nation (
n_nationkey tinyint NOT NULL,
n_name char(25) NOT NULL,
n_regionkey tinyint NOT NULL,
n_comment char(152) NOT NULL,
PRIMARY KEY (n_nationkey)
);
​
CREATE TABLE new_order (
no_o_id int NOT NULL,
no_d_id int NOT NULL,
no_w_id int NOT NULL,
PRIMARY KEY (no_w_id,no_d_id,no_o_id)
);
​
​
CREATE TABLE orderline (
ol_o_id int NOT NULL,
ol_d_id tinyint NOT NULL,
ol_w_id int NOT NULL,
ol_number tinyint NOT NULL,
ol_i_id int DEFAULT NULL,
ol_supply_w_id int DEFAULT NULL,
ol_delivery_d date DEFAULT NULL,
ol_quantity smallint DEFAULT NULL,
ol_amount decimal(6,2) DEFAULT NULL,
ol_dist_info char(24) DEFAULT NULL,
PRIMARY KEY (ol_w_id,ol_d_id,ol_o_id,ol_number),
KEY fk_orderline_order (ol_w_id,ol_d_id,ol_o_id),
KEY fk_orderline_stock (ol_supply_w_id,ol_i_id)
);
​
​
CREATE TABLE orders (
o_id int NOT NULL,
o_d_id int NOT NULL,
o_w_id int NOT NULL,
o_c_id int DEFAULT NULL,
o_entry_d datetime DEFAULT NULL,
o_carrier_id int DEFAULT NULL,
o_ol_cnt int DEFAULT NULL,
o_all_local int DEFAULT NULL,
PRIMARY KEY (o_w_id,o_d_id,o_id),
KEY idx_order (o_w_id,o_d_id,o_c_id,o_id)
);
​
​
CREATE TABLE region (
r_regionkey tinyint NOT NULL,
r_name char(55) NOT NULL,
r_comment char(152) NOT NULL,
PRIMARY KEY (r_regionkey)
);
​
​
CREATE TABLE stock (
s_i_id int NOT NULL,
s_w_id int NOT NULL,
s_quantity int DEFAULT NULL,
s_dist_01 char(24) DEFAULT NULL,
s_dist_02 char(24) DEFAULT NULL,
s_dist_03 char(24) DEFAULT NULL,
s_dist_04 char(24) DEFAULT NULL,
s_dist_05 char(24) DEFAULT NULL,
s_dist_06 char(24) DEFAULT NULL,
s_dist_07 char(24) DEFAULT NULL,
s_dist_08 char(24) DEFAULT NULL,
s_dist_09 char(24) DEFAULT NULL,
s_dist_10 char(24) DEFAULT NULL,
s_ytd int DEFAULT NULL,
s_order_cnt int DEFAULT NULL,
s_remote_cnt int DEFAULT NULL,
s_data varchar(50) DEFAULT NULL,
PRIMARY KEY (s_w_id,s_i_id)
) ;
​
​
CREATE TABLE supplier (
s_suppkey smallint NOT NULL,
s_name char(25) NOT NULL,
s_address char(40) NOT NULL,
s_nationkey tinyint NOT NULL,
s_phone char(15) NOT NULL,
s_acctbal decimal(12,2) NOT NULL,
s_comment char(101) NOT NULL,
PRIMARY KEY (s_suppkey)
);
​
​
CREATE TABLE warehouse (
w_id int NOT NULL,
w_name varchar(10) DEFAULT NULL,
w_street_1 varchar(20) DEFAULT NULL,
w_street_2 varchar(20) DEFAULT NULL,
w_city varchar(20) DEFAULT NULL,
w_state char(2) DEFAULT NULL,
w_zip char(9) DEFAULT NULL,
w_tax decimal(4,4) DEFAULT NULL,
w_ytd decimal(12,2) DEFAULT NULL,
PRIMARY KEY (w_id)
);

4.2 导入数据

导入数据前，注意要对tidb运行以下命令  

​
ALTER DATABASE tpcch SET tiflash replica 1;
​
mysql> SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcch';
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| tpcch | customer | 90 | 1 | | 0 | 0 |
| tpcch | district | 93 | 1 | | 0 | 0 |
| tpcch | history | 96 | 1 | | 0 | 0 |
| tpcch | item | 99 | 1 | | 0 | 0 |
| tpcch | nation | 102 | 1 | | 0 | 0 |
| tpcch | new_order | 105 | 1 | | 0 | 0 |
| tpcch | neworder | 108 | 1 | | 0 | 0 |
| tpcch | order | 111 | 1 | | 0 | 0 |
| tpcch | order_line | 113 | 1 | | 0 | 0 |
| tpcch | orderline | 115 | 1 | | 0 | 0 |
| tpcch | orders | 117 | 1 | | 0 | 0 |
| tpcch | region | 119 | 1 | | 0 | 0 |
| tpcch | stock | 121 | 1 | | 0 | 0 |
| tpcch | warehouse | 125 | 1 | | 0 | 0 |
| tpcch | supplier | 128 | 1 | | 0 | 0 |
+--------------+------------+----------+---------------+-----------------+-----------+----------+
15 rows in set (0.00 sec)
​
​
​
LOAD DATA local INFILE '/tmp/chBenchmark1/CUSTOMER.tbl' INTO TABLE tpcch.customer FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/DISTRICT.tbl' INTO TABLE tpcch.district FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/HISTORY.tbl' INTO TABLE tpcch.history FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/ITEM.tbl' INTO TABLE tpcch.item FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/NATION.tbl' INTO TABLE tpcch.nation FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/NEWORDER.tbl' INTO TABLE tpcch.new_order FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/ORDER.tbl' INTO TABLE tpcch.orders FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/ORDERLINE.tbl' INTO TABLE tpcch.orderline FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/REGION.tbl' INTO TABLE tpcch.region FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/STOCK.tbl' INTO TABLE tpcch.stock FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/SUPPLIER.tbl' INTO TABLE tpcch.supplier FIELDS TERMINATED BY '|';
LOAD DATA local INFILE '/tmp/chBenchmark1/WAREHOUSE.tbl' INTO TABLE tpcch.warehouse FIELDS TERMINATED BY '|';

4.3 运行压测命令

192.168.2.x上面安装tiup bench

tiup install bench  

持续对TIDB的数据库tpcch发起50个TP并发量，并进行一次AP的21个语句查询
tiup bench ch --host 192.168.1.x -Uhenley -pxxxxxx -P4000 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m
​
持续对mysql的数据库tpcch发起50个TP并发量，并进行一次AP的21个语句查询
tiup bench ch --host 192.168.1.x -Uhenley -pxxxxxx -P3306 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m

4.4 测试摘要

tiup bench ch --host 192.168.1.x  -Uhenley  -pxxxxxx -P3306 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m  

​
​
tpmC: 4168.9, tpmTotal: 9231.7, efficiency: 32417.2%
[Summary] Q1 - Count: 1, Sum(ms): 67.7, Avg(ms): 67.7
[Summary] Q10 - Count: 1, Sum(ms): 30.6, Avg(ms): 30.6
[Summary] Q11 - Count: 1, Sum(ms): 558.8, Avg(ms): 558.6
[Summary] Q12 - Count: 1, Sum(ms): 19.8, Avg(ms): 19.8
[Summary] Q13 - Count: 1, Sum(ms): 163.9, Avg(ms): 163.9
[Summary] Q14 - Count: 1, Sum(ms): 14.5, Avg(ms): 14.5
[Summary] Q15_ERR - Count: 1, Sum(ms): 277.5, Avg(ms): 277.5
[Summary] Q2 - Count: 1, Sum(ms): 1360.0, Avg(ms): 1359.5
[Summary] Q3 - Count: 1, Sum(ms): 90.3, Avg(ms): 90.3
[Summary] Q4 - Count: 1, Sum(ms): 116.4, Avg(ms): 116.4
[Summary] Q5 - Count: 1, Sum(ms): 204.9, Avg(ms): 204.8
[Summary] Q6 - Count: 1, Sum(ms): 18.9, Avg(ms): 18.9
[Summary] Q7 - Count: 1, Sum(ms): 21.2, Avg(ms): 21.3
[Summary] Q8 - Count: 1, Sum(ms): 195.2, Avg(ms): 195.1
[Summary] Q9 - Count: 1, Sum(ms): 265.0, Avg(ms): 265.0
QphH: 62.5
​
​
tiup bench ch --host 192.168.2.xx -Uhenley -pP@xxx -P4000 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m
tpmC: 1805.5, tpmTotal: 4092.0, efficiency: 14039.7%
[Summary] Q1 - Count: 1, Sum(ms): 145.6, Avg(ms): 145.6
[Summary] Q10 - Count: 1, Sum(ms): 275.2, Avg(ms): 275.1
[Summary] Q11 - Count: 1, Sum(ms): 330.5, Avg(ms): 330.4
[Summary] Q12 - Count: 1, Sum(ms): 124.3, Avg(ms): 124.4
[Summary] Q13 - Count: 1, Sum(ms): 98.4, Avg(ms): 98.4
[Summary] Q14 - Count: 1, Sum(ms): 275.1, Avg(ms): 275.1
[Summary] Q15_ERR - Count: 1, Sum(ms): 1.1, Avg(ms): 1.1
[Summary] Q2 - Count: 1, Sum(ms): 469.7, Avg(ms): 469.6
[Summary] Q3 - Count: 1, Sum(ms): 283.8, Avg(ms): 283.8
[Summary] Q4 - Count: 1, Sum(ms): 481.1, Avg(ms): 481.2
[Summary] Q5 - Count: 1, Sum(ms): 256.7, Avg(ms): 256.7
[Summary] Q6 - Count: 1, Sum(ms): 98.1, Avg(ms): 98.1
[Summary] Q7 - Count: 1, Sum(ms): 192.4, Avg(ms): 192.3
[Summary] Q8 - Count: 1, Sum(ms): 143.1, Avg(ms): 143.1
[Summary] Q9 - Count: 1, Sum(ms): 667.7, Avg(ms): 667.7
QphH: 62.4

4.4 测试总结

保留对 MySQL8.0 和 TiDB6.0 的内部参数不变， 单纯从单机 load data 数据插入、 tpmC 性能、以及 tpc-h 的性能数据表面来看，MySQL8.0 要比 TiDB6.0 要好。然而，实际情况并非如此，因为 TiDB 还有很大的调优空间。正如前面提到的，它们是两个不同的产品线，但这里证明了 TiDB 的友好性。它是十分兼容 MySQL 的，如果你从单机版的 TiDB 开始，随着业务的扩大，你可以自由、轻松地进行扩展。

我对 TiDB 的展望

软件开发的角度，TiDB 的解耦是完整的，如今 TiDB 已经发展到了 7.0 版本。 我对 TiDB 未来的期待有三个方面 ： TiDB 模块源代码，可以做为分布式计算基础参考，派生更多的可能性，类似 presto 的路线延伸；TiKV 模块源代码，可以作为分布式存储参考，以后的发展方向可能是文件数据存储；PD 模块源代码的技术路径发展是轻量级的元数据存储的管理，三者兼进，TiDB 将能够最大化地帮助用户降低存储成本，提升计算弹性，通过分布式实现元数据最优存储，灵活、可靠，在更多场景得到应用。