一、环境
tpc-H 100G数据 2.8版本
22个场景sql：
<https://github.com/pingcap/tidb-bench/tree/master/tpch/queries>
官方：
节点数量：3
CPU：Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz，40 核
内存：189 GB
磁盘：NVMe 3TB * 2
华为云：
kc1.4xlarge.4
节点数量：6
CPU：16vCPUs（kunpeng 920）
内存：64 GB
磁盘：极速SSD（fio bs=1M job=10 w=8783MiB/s,8782 IOPS）
布局：tikv和tiflash同一主机*3，tidb和pd在同一主机*3，绑2node
普通SSD：
TaiShan
节点数量：6
CPU：128 CPU（kunpeng 920）
内存：512 GB
磁盘：普通SSD（fio bs=16k w=250MB/s）
布局：
1、每台主机4块数据SSD，共同加到一个tiflash中
2、24*TiDB，3*PD，24Tikv，6Tiflash，每个server端单独绑一个node（一个node 32CPU）
二、参数设置
tiup cluster edit-config t1
tiflash：
profiles.default.max_memory_usage = 10000000000000
set global tidb_allow_mpp=1;
set @@tidb_isolation_read_engines='tiflash';
set @@tidb_mem_quota_query = 10 << 30;
因为tidb_isolation_read_engines只能session级别，通过mysql客户端登陆调用本地脚本方式执行
mysql -h127.0.0.1 -uroot -P4000 -D tpch <<!
\\. 1.sql
!
执行多次，直到sql执行时间趋于稳定
三、测试结果
| 官方数据 | 华为云3副本Tiflash | 华为云3副本tikv+tiflash | 普通SSD 6副本tikv+tiflash |
|---|
| Q1 | 8.08 | 6.6 | | 1.68 | | Q2 | 2.53 | 2.48 | | 3.09 | | Q3 | 4.84 | 4.649 | | 15.76 | | Q4 | 10.94 | 5.589 | 19.1 | 8.27 | | Q5 | 12.27 | 11.02 | | 6.97 | | Q6 | 1.32 | 1 | | 0.55 | | Q7 | 5.91 | 4.0666 | | 7.59 | | Q8 | 6.71 | 7.1 | | 14.91 | | Q9 | 44.19 | 30.334 | | 12.87 | | Q10 | 7.13 | 4.4 | | 41.04 | | Q11 | 2.18 | 1.771 | | 3.03 | | Q12 | 2.88 | 2.885 | | 2.47 | | Q13 | 6.84 | 4.9 | | 72.62 | | Q14 | 1.69 | 1.5 | | 1.51 | | Q15 | 3.29 | 2.5-2.7 | 2.5-2.9 | 13.75 | | Q16 | 5.04 | 1.1 | | 2.07 | | Q17 | 11.7 | 7.9 | | 24.89 | | Q18 | 12.87 | 11.1 | | 14.17 | | Q19 | 4.75 | 3.05 | | 1.38 | | Q20 | 8.89 | 2.4 | | 24.62 | | Q21 | 24.44 | 12.4 | | 15.47 | | Q22 | 1.23 | 1.167 | | 1.4 |
四、结果说明及一些猜想
Q4：
select
o_orderpriority,count(*) as order_count
from
orders
where
o_orderdate >= '1995-01-01'
and o_orderdate < date_add('1995-01-01', interval '3' month)
and exists (
select * from lineitem
where
l_orderkey = o_orderkey
and l_commitdate < l_receiptdate
)
group by o_orderpriority
order by o_orderpriority;
tiflash：5.589s
tikv+tiflash+tidb（默认配置）：19.1s
explain analyze执行计划，默认配置下表lineitem走了cache：
Selection_24(Probe) ? ? ? ? ?| 3.98 ? ? ? ? | 14185840 ?| cop[tikv] ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |time:5m56.6s, **loops:16883**,?
cop_task: {num: 3827, max: 697.5ms, min: 585.8μs, avg: 133ms, p95: 340ms, max_proc_keys: 17867, p95_proc_keys: 15901, tot_proc: 7m13.6s, tot_wait: 1m6.1s, rpc_num: 3827, rpc_time: 8m29s, copr_cache_hit_ratio: 0.24}, tikv_task:{proc max:530ms, min:0s, p80:180ms, p95:280ms, iters:39261, tasks:3827}, scan_detail: {total_process_keys: 21217578, total_process_keys_size: 4216268171, total_keys: 25622316, rocksdb: {delete_skipped_count: 0, key_skipped_count: 20513898,?
block: {**cache_hit_count: 32099284, read_count: 1750183, read_byte: 29.1 GB**}}} ??
| lt(tpch.lineitem.l_commitdate, tpch.lineitem.l_receiptdate)
?
在强制tiflash下，优化器重组了sql，两张表直接做hashjoin
HashJoin_42 | 4471364.76 | batchCop[tiflash] || semi join, equal:[eq(tpch.orders.o_orderkey, tpch.lineitem.l_orderkey)]
一些猜想：
1、TiDB优化器中cache hit权重更高？
2、TiDB优化器之后是否会像Oracle加入硬件性能参数计算代价？（参考aux_stats$）
Q9：
tiflash和tikv+tiflash差距不大；表supplier在tikv中走的点查，非常快
耗时上，默认配置总时间更短
其他：
AP还是看存储，多盘在某些场景下貌似不能弥补性能上的差距
|