简介：TPC-H V3.0.1 是面向数据仓库与商业智能领域的标准化基准测试套件，适合数据库内核研发、数仓性能调优及数据分析方向的工程师与研究者使用。它通过模拟真实企业级数据仓库运行环境，提供一套可复现的复杂查询负载，用于衡量数据库系统在数据处理与查询响应上的性能表现，是选型对比、压测验证与教学实验的常用工具。资源包共约2000个文件，整体约24.07MB，以27个SQL查询脚本为核心，辅以大量数据分片文件、subparam参数文件、sh执行脚本及少量说明文档，覆盖建表、加载、查询与参数化测试的完整链路。目前已有335人学习下载。借助这套材料，读者可快速搭建TPC-H测试环境，对照标准查询集验证优化效果，并参考参数文件理解不同规模数据下的测试组织方式，为数据库性能评估与调优实践提供直接支撑。
1. 拆开 TPC-H V3.0.1：一份让数据库选型不再拍脑袋的基准测试资源
上周有个做数仓的朋友找我吐槽，说他们选型时被某数据库的跑分报告坑了——官方宣称的查询性能在实际业务里根本跑不出来。我问他用的什么基准，他说是随手写的几条 SQL。这就是问题所在：没有标准化的测试集，性能对比就是玄学。TPC-H V3.0.1 正是解决这个问题的资源包，它是一套面向决策支持系统的基准测试标准，包含 22 条复杂查询和 8 张数据表的结构定义，能让你在统一口径下对比不同数据仓库产品的真实表现。这份资源适合三类人：正在做数据库选型的架构师、需要验证数仓性能的 DBA、以及想深入理解 SQL 优化边界的开发者。它不教你写 SQL，但给你一把尺子，量出每个引擎的深浅。
2. TPC-H 的 22 条查询与 8 张表：从数据模型到查询语义
2.1 八张表的关系骨架与业务含义
TPC-H 的数据模型模拟了一个全球零部件供应商的业务场景，八张表分成三类。第一类是订单域：orders存订单头信息，lineitem存订单行明细，这两张表是数据量最大的，在 SF=1（约 1GB 数据量）时lineitem大约 600 万行。第二类是供应链域：part存零件信息，partsupp存供应商与零件的关联及供应成本，supplier存供应商信息。第三类是客户与区域域：customer存客户信息，nation和region是地理维度表，数据量极小但参与大量关联。
这八张表的关联关系不是随意设计的。lineitem通过l_orderkey关联orders，通过l_partkey和l_suppkey关联partsupp，partsupp再分别关联part和supplier。customer通过c_nationkey关联nation，nation通过n_regionkey关联region。这种星型与雪花混合的模型，恰好覆盖了数仓中最典型的关联模式：事实表与维度表的多层连接。
理解这个模型的意义在于：当你看到某数据库在 TPC-H 上跑得快，你要知道它快在哪。是lineitem和orders的大表关联做得好，还是nation、region这种小表广播效率高？不同引擎的优化器策略差异，会在这八张表的连接顺序和连接算法选择上暴露无遗。
2.2 22 条查询的语义分类与考察重点
22 条查询不是随便凑数的，它们按业务语义可以分成几组。定价汇总类查询（Q1、Q6）考察全表扫描和聚合能力，Q1 对lineitem做全表扫描后按退货标志、发货日期等分组计算金额，Q6 则是带过滤条件的汇总。这两条查询最能看出列式存储和向量化执行的优势。
订单优先级分析类（Q3、Q5、Q10、Q12、Q14、Q19）涉及多表关联加过滤，考察优化器的连接顺序选择。比如 Q5 要关联customer、orders、lineitem、supplier、nation、region六张表，计算某区域某年的收入。优化器如果选错驱动表，性能差距可能是数量级的。
供应商与零件分析类（Q2、Q9、Q11、Q16、Q20、Q21）考察子查询和半连接的处理能力。Q21 尤其典型，它要找那些在某个国家供应过零件、但从未被该国家客户下单的供应商，涉及NOT EXISTS和EXISTS的嵌套，对优化器的子查询展开策略是硬考验。
还有一类是影响订单分析（Q4、Q17、Q18、Q22），考察的是条件过滤与聚合的组合。Q18 要找出订单总量超过 300 的客户，先聚合再过滤，对HAVING子句的执行效率有要求。
注意：22 条查询中有多条包含
date类型的区间过滤，不同数据库对日期函数的处理方式不同，这往往是性能差异的隐藏来源。
2.3 数据生成器的参数与规模选择
TPC-H 配套的dbgen工具通过-s参数控制数据规模，SF=1 约 1GB，SF=100 约 100GB，SF=1000 约 1TB。选择规模时有个血泪经验：不要一上来就跑 SF=1000，先跑 SF=1 验证查询正确性，再逐步放大。因为某些数据库在小数据量下优化器会选错计划，但数据量上来后反而正常，反之亦然。
# 生成 SF=10 的数据，约 10GB ./dbgen -s 10 -f # 生成后检查文件 ls -lh *.tbl # 应看到 customer.tbl、lineitem.tbl、nation.tbl 等八个文件-f参数表示覆盖已有文件，不加的话如果文件已存在会报错。生成后的.tbl文件是管道符分隔的文本，需要导入数据库。导入时注意lineitem的日期格式是YYYY-MM-DD，某些数据库需要显式指定日期格式。
2.4 查询执行计划的解读方法
拿到一个数据库的 TPC-H 跑分，不要只看总耗时。用EXPLAIN或EXPLAIN ANALYZE看每条查询的执行计划，重点关注三个点：连接算法是 hash join 还是 nested loop，聚合是 hash aggregate 还是 sort aggregate，有没有出现意外的全表扫描。
以 Q5 为例，如果执行计划显示先对lineitem做全表扫描再与orders连接，而orders上有年份过滤条件，那说明优化器没有把过滤条件下推。这种情况下即使总耗时看起来还行，也说明优化器有改进空间。反过来，如果计划显示nation和region被广播到所有节点，那说明小表广播策略生效了。
-- 以 Q5 为例，查看执行计划 EXPLAIN ANALYZE SELECT n_name, SUM(l_extendedprice * (1 - l_discount)) AS revenue FROM customer, orders, lineitem, supplier, nation, region WHERE c_custkey = o_custkey AND l_orderkey = o_orderkey AND l_suppkey = s_suppkey AND c_nationkey = s_nationkey AND s_nationkey = n_nationkey AND n_regionkey = r_regionkey AND r_name = 'ASIA' AND o_orderdate >= DATE '1994-01-01' AND o_orderdate < DATE '1995-01-01' GROUP BY n_name ORDER BY revenue DESC;这条查询的关键在于r_name = 'ASIA'这个过滤条件能否尽早生效。如果优化器先做六表连接再过滤，那region表虽然小，但连接顺序错了会导致中间结果集膨胀。常见做法是先用region和nation过滤出亚洲国家，再与supplier和customer关联，最后才碰lineitem和orders。
3. 跑通 TPC-H 的完整流程：从建表到出报告
3.1 建表脚本的适配与修改
TPC-H 标准包里的dss.ddl是通用建表语句，但直接拿到目标数据库上跑通常会翻车。翻车点集中在数据类型上：标准用的是DECIMAL(15,2)，但某些数据库对DECIMAL的精度处理不同；日期类型标准写的是DATE，但有的数据库需要TIMESTAMP；字符类型标准是CHAR(1)，有的数据库对定长字符的处理会影响存储和比较效率。
我一般会先跑一遍原始 DDL，看哪里报错，然后逐条改。改的时候注意：lineitem表的l_shipdate、l_commitdate、l_receiptdate三个日期字段经常被用来做区间过滤，如果数据库支持日期分区，可以考虑按l_shipdate做范围分区。orders表的o_orderdate也是高频过滤字段，同样值得考虑分区。
-- 以 lineitem 为例，适配后的建表语句（以某列式数据库为例） CREATE TABLE lineitem ( l_orderkey BIGINT NOT NULL, l_partkey BIGINT NOT NULL, l_suppkey BIGINT NOT NULL, l_linenumber INT NOT NULL, l_quantity DECIMAL(15,2) NOT NULL, l_extendedprice DECIMAL(15,2) NOT NULL, l_discount DECIMAL(15,2) NOT NULL, l_tax DECIMAL(15,2) NOT NULL, l_returnflag CHAR(1) NOT NULL, l_linestatus CHAR(1) NOT NULL, l_shipdate DATE NOT NULL, l_commitdate DATE NOT NULL, l_receiptdate DATE NOT NULL, l_shipinstruct CHAR(25) NOT NULL, l_shipmode CHAR(10) NOT NULL, l_comment VARCHAR(44) NOT NULL ) PARTITION BY RANGE (l_shipdate);分区键的选择要看查询模式。Q1 和 Q6 都带l_shipdate过滤，按这个字段分区能让分区裁剪生效。但注意分区粒度不要太细，按天分区在 SF=100 时会产生大量小分区，反而拖慢元数据管理。按月分区是常见折中。
3.2 数据导入的批量优化
导入.tbl文件时，逐条INSERT是最慢的方式，没有之一。常见做法是用数据库自带的批量导入工具，比如COPY、LOAD DATA或\copy。如果数据库支持并行导入，把八个文件分到不同会话同时导入，能显著缩短时间。
# 以 PostgreSQL 为例，用 COPY 命令导入 psql -d tpch -c "\COPY lineitem FROM 'lineitem.tbl' WITH (FORMAT csv, DELIMITER '|')" psql -d tpch -c "\COPY orders FROM 'orders.tbl' WITH (FORMAT csv, DELIMITER '|')" # 其余表类似导入顺序有讲究：先导小表region、nation，再导supplier、customer、part，最后导partsupp、orders、lineitem。这样如果外键约束存在，不会因为引用缺失而报错。导入完成后跑ANALYZE或UPDATE STATISTICS收集统计信息，否则优化器可能因为不知道数据分布而选错计划。
提示：导入前临时关闭外键约束和触发器，导入后再开启，能省下大量检查时间。但记得导入后要验证数据完整性。
3.3 查询执行的参数调优
22 条查询不是每条都跑一遍就完事。执行前要确认几个关键参数：并行度设置、内存分配、临时空间。并行度太低跑不出硬件性能，太高会导致资源争抢。我一般从 CPU 核数的一半开始试，比如 16 核机器先设 8 并行度，看 CPU 利用率再调整。
内存分配要看查询的中间结果集大小。Q9 和 Q21 的中间结果可能很大，如果排序或哈希聚合的内存不够，会溢写到磁盘，性能断崖式下跌。监控执行过程中的临时文件写入量，如果发现大量磁盘临时文件，说明内存不够。
-- 以某数据库为例，设置查询级并行度和内存 SET max_parallel_workers_per_gather = 8; SET work_mem = '256MB'; SET maintenance_work_mem = '1GB'; -- 执行 Q9 并记录耗时 \timing on \i q9.sqlwork_mem不是越大越好，设太大可能导致内存溢出。一般建议单条查询的work_mem不超过总内存的 25%，因为一个查询可能有多个排序或哈希节点同时消耗内存。
3.4 结果校验与性能指标计算
跑完查询后要校验结果正确性。TPC-H 标准包里有answers目录，存放了 SF=1 时 22 条查询的预期结果。把实际结果与预期结果对比，行数和关键聚合值要一致。如果结果不对，先检查数据导入是否完整，再检查查询语句是否被意外修改。
性能指标有两个：总耗时和单查询耗时。总耗时是所有查询耗时之和，但要注意有的测试规范要求跑两遍取第二遍的时间，因为第一遍可能有冷缓存影响。单查询耗时用来定位瓶颈，如果某条查询特别慢，单独拿出来分析执行计划。
# 简单的耗时记录脚本 for i in $(seq 1 22); do start=$(date +%s%N) psql -d tpch -f q${i}.sql > /dev/null 2>&1 end=$(date +%s%N) echo "Q${i}: $(( (end - start) / 1000000 )) ms" done这个脚本只记录总耗时，不区分解析、执行、取数阶段。更精细的做法是用数据库自带的性能视图，比如pg_stat_statements或performance_schema，能看到每个阶段的耗时分解。
4. 避坑指南：TPC-H 跑分中常见的五个翻车现场
4.1 数据生成不完整导致查询结果对不上
现象：Q1 返回的行数比预期少，或者 Q6 的汇总金额与标准答案有偏差。
原因：dbgen生成数据时如果中途中断，.tbl文件可能不完整。或者导入时用了HEADER选项，把第一行数据当成了列名。还有一种情况是lineitem表的l_linenumber字段在导入时被当成字符串处理，导致排序结果异常。
解决：生成数据后检查每个文件的行数，lineitem在 SF=1 时应该是 6001215 行。导入时确认分隔符和引号处理正确，导入后跑COUNT(*)验证。如果行数对不上，重新生成和导入。
4.2 统计信息缺失导致优化器选错计划
现象：同一条查询，第一次跑很慢，第二次跑很快，或者反过来。执行计划显示用了 nested loop 而不是 hash join。
原因：导入数据后没有收集统计信息，优化器只能凭默认值估算行数。对于lineitem这种大表，默认估算可能差几个数量级，导致连接顺序和连接算法选择完全错误。
解决：导入后立即对每张表执行ANALYZE。如果数据库支持直方图统计，对l_shipdate、o_orderdate等过滤字段额外收集。统计信息收集后，再跑一遍查询看计划是否改变。
4.3 并行度设置不当引发资源争抢
现象：提高并行度后，单条查询反而变慢，或者多条查询并发时总耗时增加。
原因：并行度超过 CPU 物理核数后，线程切换开销超过并行收益。或者多个查询同时跑，每个都开高并行度，导致内存和 IO 争抢。
解决：并行度从 CPU 核数的一半开始试，逐步调整。跑分时一次只跑一条查询，避免并发干扰。如果必须并发测试，降低单查询并行度，用吞吐量而非单查询延迟作为指标。
4.4 日期格式与函数差异导致查询语义偏移
现象：Q5 和 Q6 的结果与标准答案有细微差异，比如金额差几块钱。
原因：不同数据库对DATE类型的隐式转换规则不同。标准查询里写的是DATE '1994-01-01'，但有的数据库需要TO_DATE('1994-01-01', 'YYYY-MM-DD')。如果格式不匹配，可能把日期当成字符串比较，导致边界值处理错误。
解决：统一用显式日期函数，不要依赖隐式转换。跑之前先用SELECT验证日期过滤的边界值是否正确。如果数据库的日期函数与标准 SQL 差异大，改写查询时保持语义一致。
4.5 缓存与预热影响跑分可比性
现象：同一套硬件，两次跑分结果差异超过 10%。
原因：第一次跑分时数据还在磁盘上，第二次跑分时数据已经在内存缓存里。如果两次跑分之间没有清缓存，对比就没有意义。
解决：跑分前清空数据库缓存和操作系统缓存。Linux 下可以用echo 3 > /proc/sys/vm/drop_caches清系统缓存，数据库层面重启实例或执行清缓存命令。每次跑分前都做同样的预热或清缓存操作，保证条件一致。
5. 进阶技巧：用 TPC-H 做 SQL 改写与索引验证
跑通标准查询只是起点。真正有意思的是拿 TPC-H 当试验田，验证你的优化思路。比如 Q1 的原始写法是对lineitem全表扫描后聚合，你可以试试加一个覆盖索引，看执行计划是否变成索引扫描。但要注意：列式数据库里索引的效果和行式数据库完全不同，别把行式数据库的经验直接搬过来。
我一般会做三组对比：第一组跑原始查询，第二组跑改写后的查询（比如把子查询改成 JOIN），第三组跑加了索引或物化视图的查询。每组跑三遍取中位数，避免单次波动。对比的时候不只看总耗时，还要看 CPU 时间、IO 等待时间、内存峰值。
-- Q1 的原始写法 SELECT l_returnflag, l_linestatus, SUM(l_quantity) AS sum_qty, SUM(l_extendedprice) AS sum_base_price, SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price, SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge, AVG(l_quantity) AS avg_qty, AVG(l_extendedprice) AS avg_price, AVG(l_discount) AS avg_disc, COUNT(*) AS count_order FROM lineitem WHERE l_shipdate <= DATE '1998-12-01' - INTERVAL '90' DAY GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; -- 改写版本：把日期计算提前，避免每行都算 WITH filtered AS ( SELECT * FROM lineitem WHERE l_shipdate <= DATE '1998-09-02' ) SELECT l_returnflag, l_linestatus, SUM(l_quantity) AS sum_qty, SUM(l_extendedprice) AS sum_base_price, SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price, SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge, AVG(l_quantity) AS avg_qty, AVG(l_extendedprice) AS avg_price, AVG(l_discount) AS avg_disc, COUNT(*) AS count_order FROM filtered GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus;改写版本把日期计算从WHERE子句里提出来，变成常量。原始写法里DATE '1998-12-01' - INTERVAL '90' DAY是常量表达式，优化器通常能折叠，但如果数据库的常量折叠做得不好，每行都算一次就是浪费。改写后语义不变，但执行计划可能更干净。
验证索引效果时，注意区分聚簇索引和非聚簇索引。在l_shipdate上建索引，如果查询过滤条件能命中索引，行式数据库可能走索引扫描；但列式数据库本身按列存储，索引的收益可能不明显，反而增加导入和维护开销。我一般会在建索引前后各跑一遍 Q1 和 Q6，看 IO 统计里的物理读次数变化。
还有一个容易被忽略的点：TPC-H 的 22 条查询里有几条对l_discount和l_quantity做了算术运算，如果数据库支持预计算列或表达式索引，可以试试把l_extendedprice * (1 - l_discount)做成物化列。但这样会改变表结构，跑标准查询时要注意兼容性。
从那以后我每次做数据库选型，都强制走一遍 TPC-H 的完整流程：生成数据、导入、收集统计、跑 22 条查询、对比执行计划、做改写验证。这套流程走下来，哪个引擎在哪个环节有短板，一目了然。希望帮到你。
本文还有配套的精品资源，点击获取
