TPCH 22条SQL语句分析 - xibuhaohao - 博客园
TPCH模型规范、测试说明及22条语句 - zhjh256 - 博客园
TPC-DS 性能比较：TiDB 与 Impala-PingCAP | 平凯星辰
揭秘Oracle TPC-H性能优化：如何提升数据库查询速度，揭秘实战技巧与挑战
引言
TPC-H（Transaction Processing Performance Council H-Scale Performance Benchmark）是一个广泛使用的数据库性能基准测试，用于衡量数据库系统在高并发和大规模数据集上的查询性能。Oracle数据库作为企业级数据库的佼佼者，其性能优化一直是数据库管理员和开发者关注的焦点。本文将深入探讨Oracle TPC-H性能优化，揭示提升数据库查询速度的实战技巧与挑战。
一、TPC-H基准测试简介
TPC-H基准测试模拟了典型的在线事务处理（OLTP）场景，包括订单处理、库存管理和客户服务等多个方面。它通过一系列复杂的SQL查询来测试数据库的性能。在TPC-H基准测试中，查询的性能是衡量数据库系统效率的重要指标。
二、TPC-H性能优化技巧
1. 索引优化
索引是提升查询性能的关键。以下是一些索引优化的技巧：
- 创建索引：针对查询中频繁使用的列创建索引，例如：
CREATE INDEX idx_order_date ON orders (order_date);
- 监控索引使用情况：定期检查索引的使用情况，确保索引被有效利用。
SELECT * FROM v$index_usage;
2. 查询优化
查询优化是提升性能的直接方法。以下是一些查询优化的技巧：
- 使用执行计划：通过分析执行计划，找出查询性能瓶颈。
EXPLAIN PLAN FOR SELECT * FROM orders WHERE order_date = '2021-01-01';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
- 优化子查询：将子查询转换为连接查询，以提高性能。
SELECT d.department_name, COUNT(e.employee_id) AS employee_count
FROM departments d
JOIN employees e ON d.department_id = e.department_id
GROUP BY d.department_name;
3. 物理设计优化
- 分区表：将大表分区可以提高查询性能。
CREATE TABLE orders (
order_id NUMBER,
order_date DATE,
...
) PARTITION BY RANGE (order_date) (
PARTITION p1 VALUES LESS THAN ('2021-01-01'),
PARTITION p2 VALUES LESS THAN ('2022-01-01'),
...
);
- 触发器和存储过程：合理使用触发器和存储过程可以提高数据一致性和查询性能。
CREATE OR REPLACE TRIGGER trig_after_insert_order
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
-- 触发器逻辑
END;
三、实战案例
以下是一个实际的TPC-H性能优化案例：
假设在TPC-H基准测试中，查询Q1（找出每个供应商的总订单数）的执行时间过长。通过分析执行计划，我们发现orders表的supplier_id列未创建索引。在创建索引后，查询性能得到了显著提升。
四、挑战与展望
TPC-H性能优化面临以下挑战：
-
数据量庞大：随着数据量的增长，性能优化变得越来越复杂。
-
多并发查询：在高并发环境下，优化查询性能是一项挑战。
未来，随着数据库技术的发展，我们将有更多高效的工具和方法来提升TPC-H性能。
结语
Oracle TPC-H性能优化是数据库管理员和开发者必须掌握的技能。通过合理的索引优化、查询优化和物理设计优化，可以有效提升数据库查询速度。在实际项目中，不断总结经验，持续优化，是提升数据库性能的关键。
TiDB TPC-H 性能对比测试报告 - v5.4 MPP 模式对比 Greenplum 6.15.0 以及 Apache Spark 3.1.1
测试概况
本次测试对比了 TiDB v5.4 MPP 模式下和主流分析引擎例如 Greenplum 和 Apache Spark 最新版本在 TPC-H 100 GB 数据下的性能表现。结果显示，TiDB v5.4 MPP 模式下相对这些方案有 2-3 倍的性能提升。
TiDB v5.0 中引入的 TiFlash 组件的 MPP 模式大大幅增强了 TiDB HTAP 形态。本文的测试对象如下：
- TiDB v5.4 MPP 执行模式下的列式存储
- Greenplum 6.15.0
- Apache Spark 3.1.1 + Parquet
测试环境
硬件配置
| 实例类型 | 实例数 |
|---|---|
| PD | 1 |
| TiDB | 1 |
| TiKV | 3 |
| TiFlash | 3 |
- CPU：Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz，40 核
- 内存：189 GB
- 磁盘：NVMe 3TB * 2
软件版本
| 服务类型 | 软件版本 |
|---|---|
| TiDB | 5.4 |
| Greenplum | 6.15.0 |
| Apache Spark | 3.1.1 |
配置参数
TiDB v5.4 配置
v5.4 的 TiDB 集群除以下配置项外均使用默认参数配置。所有 TPC-H 测试表均以 TiFlash 列存进行同步，无额外分区和索引。
在 TiFlash 的 users.toml 配置文件中进行如下配置：
[profiles.default] max_memory_usage = 10000000000000
使用 SQL 语句设置以下会话变量：
set @@tidb_isolation_read_engines='tiflash'; set @@tidb_allow_mpp=1; set @@tidb_mem_quota_query = 10 << 30;
Greenplum 配置
Greenplum 集群使用额外的一台 Master 节点部署（共四台），每台 Segment Server 部署 8 Segments（每个 NVMe SSD 各 4 个），总共 24 Segments。存储格式为 append-only / 列式存储，分区键为主键。
log_statement = all gp_autostats_mode = none statement_mem = 2048MB gp_vmem_protect_limit = 16384
Apache Spark 配置
Apache Spark 测试使用 Apache Parquet 作为存储格式，数据存储在 HDFS 上。HDFS 为三节点，为每个节点指定两块 NVMe SSD 盘作为数据盘。通过 Standalone 方式启动 Spark 集群，使用 NVMe SSD 盘作为 spark.local.dir 本地目录以借助快速盘加速 Shuffle Spill 过程，无额外分区和索引。
--driver-memory 20G --total-executor-cores 120 --executor-cores 5 --executor-memory 15G
测试结果
注意
以下测试结果均为 3 次测试的平均值，单位均为秒。
| Query ID | TiDB v5.4 | Greenplum 6.15.0 | Apache Spark 3.1.1 + Parquet |
|---|---|---|---|
| 1 | 8.08 | 64.1307 | 52.64 |
| 2 | 2.53 | 4.76612 | 11.83 |
| 3 | 4.84 | 15.62898 | 13.39 |
| 4 | 10.94 | 12.88318 | 8.54 |
| 5 | 12.27 | 23.35449 | 25.23 |
| 6 | 1.32 | 6.033 | 2.21 |
| 7 | 5.91 | 12.31266 | 25.45 |
| 8 | 6.71 | 11.82444 | 23.12 |
| 9 | 44.19 | 22.40144 | 35.2 |
| 10 | 7.13 | 12.51071 | 12.18 |
| 11 | 2.18 | 2.6221 | 10.99 |
| 12 | 2.88 | 7.97906 | 6.99 |
| 13 | 6.84 | 10.15873 | 12.26 |
| 14 | 1.69 | 4.79394 | 3.89 |
| 15 | 3.29 | 10.48785 | 9.82 |
| 16 | 5.04 | 4.64262 | 6.76 |
| 17 | 11.7 | 74.65243 | 44.65 |
| 18 | 12.87 | 64.87646 | 30.27 |
| 19 | 4.75 | 8.08625 | 4.7 |
| 20 | 8.89 | 15.47016 | 8.4 |
| 21 | 24.44 | 39.08594 | 34.83 |
| 22 | 1.23 | 7.67476 | 4.59 |
以上性能图中蓝色为 TiDB v5.4，红色为 Greenplum 6.15.0，黄色为 Apache Spark 3.1.1，纵坐标是查询的处理时间。纵坐标数值越低，表示 TPC-H 性能越好。
TiDB TPC-H 性能对比测试报告 - v4.0 对比 v3.0
测试目的
对比 TiDB v4.0 和 v3.0 OLAP 场景下的性能。
因为 TiDB v4.0 中新引入了 TiFlash 组件增强 TiDB HTAP 形态，本文的测试对象如下：
- v3.0 仅从 TiKV 读取数据。
- v4.0 仅从 TiKV 读取数据。
- v4.0 通过智能选择混合读取 TiKV、TiFlash 的数据。
测试环境 (AWS EC2)
硬件配置
| 服务类型 | EC2 类型 | 实例数 |
|---|---|---|
| PD | m5.xlarge | 3 |
| TiDB | c5.4xlarge | 2 |
| TiKV & TiFlash | i3.4xlarge | 3 |
| TPC-H | m5.xlarge | 1 |
软件版本
| 服务类型 | 软件版本 |
|---|---|
| PD | 3.0、4.0 |
| TiDB | 3.0、4.0 |
| TiKV | 3.0、4.0 |
| TiFlash | 4.0 |
| tiup-bench | 0.2 |
配置参数
v3.0
v3.0 的 TiDB 和 TiKV 均为默认参数配置。
变量配置
set global tidb_distsql_scan_concurrency = 30; set global tidb_projection_concurrency = 16; set global tidb_hashagg_partial_concurrency = 16; set global tidb_hashagg_final_concurrency = 16; set global tidb_hash_join_concurrency = 16; set global tidb_index_lookup_concurrency = 16; set global tidb_index_lookup_join_concurrency = 16;
v4.0
v4.0 的 TiDB 为默认参数配置。
TiKV 配置
readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true
PD 配置
replication.enable-placement-rules: true
TiFlash 配置
logger.level: "info" learner_config.log-level: "info"
变量配置
注意
部分参数为 SESSION 变量。建议所有查询都在当前 SESSION 中执行。
set global tidb_allow_batch_cop = 1; set session tidb_opt_distinct_agg_push_down = 1; set global tidb_distsql_scan_concurrency = 30; set global tidb_projection_concurrency = 16; set global tidb_hashagg_partial_concurrency = 16; set global tidb_hashagg_final_concurrency = 16; set global tidb_hash_join_concurrency = 16; set global tidb_index_lookup_concurrency = 16; set global tidb_index_lookup_join_concurrency = 16;
测试方案
硬件准备
为了避免 TiKV 和 TiFlash 争抢磁盘和 I/O 资源，把 EC2 配置的两个 NVMe SSD 盘分别挂载为 /data1 及 /data2，把 TiKV 的部署至 /data1，TiFlash 部署至 /data2。
测试过程
-
通过 TiUP 部署 TiDB v4.0 和 v3.0。
-
通过 TiUP 的 bench 工具导入 TPC-H 10G 数据。
-
执行以下命令将数据导入 v3.0：
tiup bench tpch prepare \ --host ${tidb_v3_host} --port ${tidb_v3_port} --db tpch_10 \ --sf 10 \ --analyze --tidb_build_stats_concurrency 8 --tidb_distsql_scan_concurrency 30 -
执行以下命令将数据导入 v4.0：
tiup bench tpch prepare \ --host ${tidb_v4_host} --port ${tidb_v4_port} --db tpch_10 --password ${password} \ --sf 10 \ --tiflash \ --analyze --tidb_build_stats_concurrency 8 --tidb_distsql_scan_concurrency 30
-
-
运行 TPC-H 的查询。
-
下载 TPC-H 的 SQL 查询文件：
git clone https://github.com/pingcap/tidb-bench.git && cd tpch/queries -
查询并记录耗时。
- 对于 TiDB v3.0，使用 MySQL 客户端连接到 TiDB，然后执行查询，记录 v3.0 查询耗时。
- 对于 TiDB v4.0，使用 MySQL 客户端连接到 TiDB，再根据测试的形态，选择其中一种操作：
- 设置
set @@session.tidb_isolation_read_engines = 'tikv,tidb';后，再执行查询，记录 v4.0 仅从 TiKV 读取数据的查询耗时。 - 设置
set @@session.tidb_isolation_read_engines = 'tikv,tiflash,tidb';后，再执行查询，记录 v4.0 通过智能选择从 TiKV 和 TiFlash 混合读取数据的查询耗时。
- 设置
-
-
提取整理耗时数据。
测试结果
注意
本测试所执行 SQL 语句对应的表只有主键，没有建立二级索引。因此以下测试结果为无索引结果。
| Query ID | v3.0 | v4.0 TiKV Only | v4.0 TiKV / TiFlash Automatically |
|---|---|---|---|
| 1 | 7.78s | 7.45s | 2.09s |
| 2 | 3.15s | 1.71s | 1.71s |
| 3 | 6.61s | 4.10s | 4.05s |
| 4 | 2.98s | 2.56s | 1.87s |
| 5 | 20.35s | 5.71s | 8.53s |
| 6 | 4.75s | 2.44s | 0.39s |
| 7 | 7.97s | 3.72s | 3.59s |
| 8 | 5.89s | 3.22s | 8.59s |
| 9 | 34.08s | 11.87s | 15.41s |
| 10 | 4.83s | 2.75s | 3.35s |
| 11 | 3.98s | 1.60s | 1.59s |
| 12 | 5.63s | 3.40s | 1.03s |
| 13 | 5.41s | 4.56s | 4.02s |
| 14 | 5.19s | 3.10s | 0.78s |
| 15 | 10.25s | 1.82s | 1.26s |
| 16 | 2.46s | 1.51s | 1.58s |
| 17 | 23.76s | 12.38s | 8.52s |
| 18 | 17.14s | 16.38s | 16.06s |
| 19 | 5.70s | 4.59s | 3.20s |
| 20 | 4.98s | 1.89s | 1.29s |
| 21 | 11.12s | 6.23s | 6.26s |
| 22 | 4.49s | 3.05s | 2.31s |
以上性能图中蓝色为 v3.0，红色为 v4.0（仅从 TiKV 读），黄色为 v4.0（从 TiKV、TiFlash 智能选取），纵坐标是查询的处理时间。纵坐标越低，表示性能越好。
- v4.0（仅从 TiKV 读取数据），即 TiDB 仅会从 TiKV 中读取数据。将该结果与 v3.0 的结果对比可得知，TiDB、TiKV 升级至 4.0 版本后，TPC-H 性能得到的提升幅度。
- v4.0（从 TiKV、TiFlash 智能选取），即 TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。将该结果与 v3.0 的结果对比可得知，在 v4.0 完整的 HTAP 形态下，TPC-H 性能得到的提升幅度。
【数据库】TiDB 5.3 TPCH 100G测试及思考
一、环境
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还是看存储，多盘在某些场景下貌似不能弥补性能上的差距
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/xyq172291/article/details/122281719
