作者：
大数据模型
对制造业、银行业、通讯业了解多一点，关怀专心国产数据库技能布道以及数据资产建造的运用实践。
导读
跟着 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/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 将能够最大化地协助用户降低存储本钱，提高核算弹性，经过分布式实现元数据最优存储，灵敏、牢靠，在更多场景得到运用。
