共计 13045 个字符，预计需要花费 33 分钟才能阅读完成。
作者：
大数据模型
对制造业、银行业、通讯业理解多一点，关怀专一国产数据库技术布道以及数据资产建设的利用实际。
导读
随着 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 步是 哪一个节点响应数据库客户的申请，分布式数据库有两种零碎架构，一种是中心化架构【master\slave】，一种是去中心化架构。中心化架构的负色职责分清，负责干活、负责指挥、负责接待用户，而去中心化架构则是每个节点角色平等，看待客户的申请，其中的一个节点会霎时切换成负责接待，残余的节点依据状况转化执行。
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）。
测试环境
硬件配置
| 操作系统 | CentOS Linux release 7.6.1810 |
|---|---|
| CPU | 8 核 Intel(R) Xeon(R) |
| 内存 | 16 |
测试配置
| 软件版本 | IP | 作用 |
|---|---|---|
| MySQL8.0 | 192.168.1.X | MySQL 单机 |
| TiDB6.0 | 192.168.1.X | TiDB 单机 |
| CH-benchmark | 192.168.2.X | HTAP 测试工具，生成数据 |
| TiUP Bench | 192.168.2.X | HTAP 测试工具，进行测试 |
生成数据
在我的试验中，我应用了 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 <WAREHOUSE_COUNT>
-pa <INITIAL_DB_GEN_PATH>
example: chBenchmark -csv -wh 50 -pa /path/to/any/directory
生成数据如下, 生成一个 warehouse 的数据
chBenchmark -csv -wh 1 -pa /tmp/chBenchmark14.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 1m4.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.44.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 将可能最大化地帮忙用户升高存储老本，晋升计算弹性，通过分布式实现元数据最优存储，灵便、牢靠，在更多场景失去利用。
