腾讯云数据库TDSQL分布键的性能对比

​

 前序

这篇文章我主要是用300万的表，来测试分布式的shadkey的性能优势；总的来说，多表关联查询时，如果走shardkey性能会根据分片数有质的提升，反之，如果不走shardkey，多表关联查询还不如单机；单表查询时，无论走不走分布键shadkey，性能都是优于单机的。

一、腾讯云TDSQL架构

TDSQL（MYSQL）是腾讯自研的一套基于MySQL内核云数据库，它集成数据库的运维、监控、备份、调优等于一身，优化传统数据库版本、集群、环境、监控比较混乱的情况，同时自主研发的区别传统的强同步功能和分布键shardkey，保证了数据的完整性的同时提高了数据库的性能，架构图摘自腾讯产品介绍：

​

二、腾讯TDSQL的分布键性能对比

1、环境说明

1.1此处我用了两套TDSQL集群，都是16C64G配置，一套为非分布式，类似单机，另外一套分布式4个分片；

1.2非分布式集群里有两个表lineitem_osk和orders_osk数据量都是300万，两表建有一个ORDERKEY字段值一样，其中lineitem_osk表里的ID字段和L_ORDERKEY，orders_osk表里的ID字段和O_ORDERKEY的值是一样的，目的是为了区分主键关联，非主键关联的查询性能，建表语句如下：

CREATE TABLE `orders_osk` (
  `id` bigint ,
  `O_ORDERKEY` bigint(20) unsigned NOT NULL ,
  `O_CUSTKEY` int(11) NOT NULL,
  `O_ORDERSTATUS` char(1) DEFAULT NULL,
  `O_TOTALPRICE` decimal(10,0) DEFAULT NULL,
  `O_ORDERDATE` date DEFAULT NULL,
  `O_ORDERPRIORITY` char(15) DEFAULT NULL,
  `O_CLERK` char(15) DEFAULT NULL,
  `O_SHIPPRIORITY` int(11) DEFAULT NULL,
  `O_COMMENT` varchar(79) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `O_ORDERKEY` (`id`)
);


CREATE TABLE `lineitem_osk` (
  `id` bigint ,
  `L_ORDERKEY` int(11) NOT NULL,
  `L_PARTKEY` int(11) NOT NULL,
  `L_SUPPKEY` int(11) NOT NULL,
  `L_LINENUMBER` int(11) NOT NULL,
  `L_QUANTITY` decimal(10,0) DEFAULT NULL,
  `L_EXTENDEDPRICE` decimal(10,0) DEFAULT NULL,
  `L_DISCOUNT` decimal(10,0) DEFAULT NULL,
  `L_TAX` decimal(10,0) DEFAULT NULL,
  `L_RETURNFLAG` char(1) DEFAULT NULL,
  `L_LINESTATUS` char(1) DEFAULT NULL,
  `L_SHIPDATE` date DEFAULT NULL,
  `L_COMMITDATE` date DEFAULT NULL,
  `L_RECEIPTDATE` date DEFAULT NULL,
  `L_SHIPINSTRUCT` char(25) DEFAULT NULL,
  `L_SHIPMODE` char(10) DEFAULT NULL,
  `L_COMMENT` varchar(44) DEFAULT NULL,
  PRIMARY KEY (`id`)
);

1.3分布式集群里有4个表（lineitem_osk和orders_osk，lineitem_ns和orders_ns),这两组表的区别是前面一组指定了分布键shardkey，后面一组没有指定，落在一个分片上，类似单机，建表语句：

CREATE TABLE `orders_osk` (
  `id` bigint ,
  `O_ORDERKEY` bigint(20) unsigned NOT NULL ,
  `O_CUSTKEY` int(11) NOT NULL,
  `O_ORDERSTATUS` char(1) DEFAULT NULL,
  `O_TOTALPRICE` decimal(10,0) DEFAULT NULL,
  `O_ORDERDATE` date DEFAULT NULL,
  `O_ORDERPRIORITY` char(15) DEFAULT NULL,
  `O_CLERK` char(15) DEFAULT NULL,
  `O_SHIPPRIORITY` int(11) DEFAULT NULL,
  `O_COMMENT` varchar(79) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `O_ORDERKEY` (`id`)
) shardkey=id;


CREATE TABLE `lineitem_osk` (
  `id` bigint ,
  `L_ORDERKEY` int(11) NOT NULL,
  `L_PARTKEY` int(11) NOT NULL,
  `L_SUPPKEY` int(11) NOT NULL,
  `L_LINENUMBER` int(11) NOT NULL,
  `L_QUANTITY` decimal(10,0) DEFAULT NULL,
  `L_EXTENDEDPRICE` decimal(10,0) DEFAULT NULL,
  `L_DISCOUNT` decimal(10,0) DEFAULT NULL,
  `L_TAX` decimal(10,0) DEFAULT NULL,
  `L_RETURNFLAG` char(1) DEFAULT NULL,
  `L_LINESTATUS` char(1) DEFAULT NULL,
  `L_SHIPDATE` date DEFAULT NULL,
  `L_COMMITDATE` date DEFAULT NULL,
  `L_RECEIPTDATE` date DEFAULT NULL,
  `L_SHIPINSTRUCT` char(25) DEFAULT NULL,
  `L_SHIPMODE` char(10) DEFAULT NULL,
  `L_COMMENT` varchar(44) DEFAULT NULL,
  PRIMARY KEY (`id`)
) shardkey=id;

2、测试结论

2.1 测试的SQL语句如下，注意其中的ID与L_ORDERKEY、O_ORDERKEY值是一样的，只是为了区分测试是不是shardkey的区别；

select count(*) from lineitem_osk a inner join orders_osk b on a.L_ORDERKEY=b.O_ORDERKEY where L_ORDERKEY<=21000000;

select count(*) from lineitem_osk a inner join orders_osk b on a.id=b.id where a.id<=21000000;

2.2分布式关联时走分布键性能比单机用主键关联时快两倍；

分布式多表联合关联不走分布键时，性能不如单机，甚至查不出来。

2.3 分布式库不指定分布键性能类似单机

3、测试过程

3.1分布式shardkey关联与单机主键关联对比

观察如下图的查询时间及执行计划，分布式关联走到分布键时速度2秒多，比单机快接近两倍，执行计划也是直接走每个分片的SIMPLE，速度很快，这里还能提升点，因为我4个分片都在一台主机上。

​

​

3.2分布式不用shardkey关联与单机非主键关联对比

分布式库关联如果不走shardkey我这次的环境是半个小时都没查出来，所以取消了；单机非主键关联比主键慢多了，但是依然比分布式的非shardkey关联快多了。

​

​

3.3分布式单表直接根据分布键查询与单机对比

单表查询根据分布键或者非分布键，分布式的速度都比单机快

​

​

​