如果你打算评估一个数据仓库或者分析型数据库能不能扛住真实业务那 TPC-DS 基本是绕不开的压测工具。它不只是一堆 SQL 脚本而是一套完整的决策支持基准规范模拟零售行业几十张表的数据模型再加上 99 条非常“刁钻”的分析型查询用来检验数据库在海量数据下的扫描、关联、聚合、窗口计算等综合能力。但很多人第一次接触 TPC-DS 时卡住的不是后面的测试而是最前面的编译安装。TPC-DS 不像 k6 这类压测工具下载个二进制就能跑它给的是 C 源码包使用前必须自己编译出dsdgen和dsqgen两个工具这里面的坑其实不少。这篇内容我会从“第一次在 Linux 上完整把 TPC-DS 跑起来”这个视角出发把编译安装的前因后果、完整步骤、验证方法以及我实际踩过的几个编译运行问题全部写清楚。无论你是刚开始研究压测工具选型还是已经被 make 报错折磨到怀疑人生这篇都有参考价值。1. 先理解TPC-DS压测工具到底是测什么的1.1 它是一套针对分析型场景的“标准考卷”很多人第一次听到 TPC-DS 会把它和 TPC-C 混淆。TPC-C 压的是联机交易系统场景是大量短事务、高频写入、行级查询而 TPC-DS 压的完全是另一类负载数据仓库里的复杂报表分析、多维聚合、ETL 之后的数据探索。TPC-DS 的模型来自一个模拟零售商的业务系统整体上由 24 张表组成其中包含 7 张事实表和 17 张维度表。事实表里存储的是 store_sales、store_returns、catalog_sales、web_sales 这类大规模销售或退货流水维度表则描述商品、客户、地区、时间、促销渠道等信息。这个模型的最大特点是它故意设计成了类似真实数仓的雪花模型或星型模型数据表之间有很深的关联路径字段类型也覆盖了数值、字符、时间等常见类型还有大量的 NULL 值、边界值、数据倾斜场景。在查询负载上TPC-DS 提供了 99 条不同的查询模板。这些查询不是简单SELECT *而是会混合出现多表 JOIN、嵌套子查询、group by 聚合、窗口函数、case when 条件分支、日期运算、集合操作等。比如一条查询可能先从 web_sales 里筛出某个时间段的数据再去关联 customer 维度、item 维度、promotion 维度最后在多个维度层级上做聚合比较。想跑得准又跑得快数据库的优化器、执行引擎、统计信息、存储格式都必须足够能打。所以我在实际交流时经常把它形容成一场“分析型 SQL 的统一考试”TPC-C 相当于测试收银台能不能快速处理结账TPC-DS 则是在考商业分析团队能不能从千万行流水里快速算出一份经营报告。后面如果要给数据仓库、分析型数据库、湖仓引擎做横向对比TPC-DS 是一个非常通用的参考基准。1.2 为什么大家都愿意把 TPC-DS 当成压测标尺判断一个压测工具值不值得用主要看三件事场景是否贴近真实、结果是否可复现、流程是否被行业认可。TPC-DS 在这三点上做得都比较到位。它有严格的规范去约束数据生成方式、查询执行方式、结果校验方式尤其是数据生成的随机种子、表的规模、SQL 参数替换规则都有明确要求。这一点很关键。我们在做数据库选型时如果每个人自己随手写几条 SQL 去压测很难保证两个数据库跑的是同一套逻辑甚至同一条 SQL 在两个库里执行计划都完全不同。而使用 TPC-DS 统一生成的数据和查询至少能做到“大家用的是同一套考卷”谁的成绩更好一目了然。另外TPC-DS 是公开标准的测试负载不是某个数据库厂商自己定义的测试工具。所以很多大厂在做技术分享时提到的“XX数据库 TPC-DS 1TB 性能评测”大家心里会有个基本预期这是规模化、复杂查询、真实数仓模型下的结果而不是压几条简单 SQL 给出的数字。作为用户我们自己也可以按文档跑出对应规模的数据验证厂商成绩是否“注水”。1.3 编译安装是进入正式压测之前的“守门员”如果在搜索引擎里搜 TPC-DS大概率会发现它压缩包里的代码形态离“开箱即用”还有一段距离。TPC-DS 官方发布的是源码包里面包含数据生成器、查询生成器和模板文件。我们真正要用的核心可执行文件有两个dsdgen负责按照指定比例因子生成原始数据文件。dsqgen负责读取查询模板生成带具体参数值的 SQL 脚本。这两个工具都需要先编译才能在当前 Linux 环境下运行。原因也很简单TPC-DS 作为标准测试工具要适配不同操作系统、不同硬件架构官方如果只给一个 Linux x86_64 的二进制那 macOS、Windows、ARM 环境就都用不了。更重要的是C/C 编译出来的二进制对系统库和 CPU 指令集非常敏感在一个老版本 glibc 上编译、拿到新版系统未必能跑反之用太新的环境编译再拿回老系统又可能因为缺少符号无法启动。自己编译虽然多一步但能保证工具和你当前测试环境完全匹配。我第一次编译 TPC-DS 时也觉得这一步很没必要后来才发现正因为它的编译过程“有点原始”才逼着使用者把目录结构、参数文件、模板路径都理解清楚。如果连工具怎么编译、如何找依赖文件都不清楚后面生成数据、替换 SQL 参数时大概率也会一头雾水。把这一步啃下来等于把整个 TPC-DS 的使用流程打通了一半。2. 编译安装前先解决三个环境细节2.1 首选 Linux x86_64但也要关注发行版差异TPC-DS 的工具集大部分教程和测试案例都默认在 Linux 上编译执行如果你是在云服务器、物理机或者容器环境里做数据库压测建议优先选择 Linux 发行版。Ubuntu/Debian、CentOS/Rocky、openEuler 这些发行版本身差异不大关键是能不能装上编译工具链。我在编译时用的是一台 Ubuntu 22.04 x86_64 服务器。为什么要强调 x86_64因为 TPC-DS 的官方 makefile 对平台有判断逻辑Linux 下最常见的MACHINE和OS配置都是LINUX。如果你的机器是 ARM 架构比如苹果 M 系列芯片的 Linux 虚机那编译参数可能要做额外调整不能完全照搬网上的命令。如果是在容器或者最小化系统里跑还要注意磁盘空间。TPC-DS 编译本身占不了多少空间但后面用-SCALE生成数据时1GB 的规模并不是只占 1GB 就结束了。以 TPC-DS 的零售模型看维度表会膨胀事实表更大加上查询过程和日志磁盘建议至少预留数据规模 3 倍以上的空间。我第一次在 / 根目录空间很小的机器上跑生成到一半报 “No space left on device”后来只能重新换数据目录相当浪费时间。2.2 提前装好编译器、make 和解析器依赖早期 TPC-DS 工具包的编译过程相对粗糙对新版 GCC 的兼容性并不是每次都理想但基本依赖还是那么几类C/C 编译器一般就是gcc和g。make用来解析 Makefile 并执行编译目标。flex和bison用于生成查询模板解析器相关代码。标准库头文件和基础命令比如binutils、unzip。在 Debian/Ubuntu 系列上可以直接安装全套apt update apt install -y build-essential flex bison在 CentOS/RHEL/Rocky 系列上可以这样yum install -y gcc gcc-c make flex bison unzip为什么要单独把 flex 和 bison 列出来因为 TPC-DS 里的dsqgen组件在编译时可能会涉及模板解析代码的生成。如果你没装这两个工具执行到一半可能会看到yacc或lex相关的报错出错后很多人会误以为是系统缺了什么大依赖实际只需要补齐这两个小工具。装完后重新make clean再make即可。编译器版本方面太老的 GCC比如 4.x编译新版 TPC-DS 工具包时可能会遇到 C11 语法不被支持的问题。如果系统自带的编译器版本实在太老建议先通过发行版的软件源安装更新的编译器或者直接在比较新的 Linux 发行版上编译。压测工具本身并不需要多高级的优化重点是要保证编译过程中语法兼容。2.3 源码包获取认准官方工具包别拿错文档在动手之前要先清楚去“哪里下载”。搜索 TPC-DS 时你会看到官网提供了两种主要下载物TPC-DS 标准规范文档PDF描述测试流程和管理规则。TPC-DS Tools 工具包zip 压缩包里面才是数据生成器和查询生成器源码。我们编译安装时需要的是第二个也就是工具包。官网对工具包的下载做了一定访问控制一般需要按页面提示填写信息后获取下载地址。这个过程很简单但需要注意别在命令行里直接使用某些临时地址因为链接可能会随会话过期。建议先用浏览器下载到本地确认 zip 包完整后再上传到服务器或放行到测试环境。也有不少开源项目把 TPC-DS 的代码做成了 GitHub 仓库比如第三方维护的tpcds-kit它们的编译脚本通常更友好甚至会自动 patch 掉一些官方源码在 macOS 和 Linux 上的兼容问题。如果你只是想在内部环境快速跑一版数据用这类第三方发行版也完全可以。但如果你要做正式的、可对外引用的性能测试那还是应该用官方发布包并且记录好版本号因为不同版本在数据分布和查询模板上存在差异混用版本会导致测试结果没有可比性。无论是官方包还是第三方包解压后第一件事不是急着编译而是先读一下 README 或者 docs 目录下的说明。很多奇怪的问题其实在文档里都已经写明白了只是大家习惯直接跳过。我在做这类工具安装时习惯把源码包顶层目录列出来先把目录结构大致过一遍mkdir -p ~/tpc-ds cd ~/tpc-ds unzip TPC-DS_Tools_v3.2.0.zip cd TPC-DS_Tools_v3.2.0 ls -la看到tools、query_templates、specification这类目录出现后就知道版本没有拿错。tools目录里放着编译源码query_templates里放着 SQL 生成模板两边后续都会用到。3. 编译安装全流程从 Makefile.suite 到 dsdgen、dsqgen3.1 解压后的目录结构与编译参数设计TPC-DS 的源码目录结构和很多传统数据库工具不太一样它不是执行一个./configure就能自动探测系统环境的而是需要你通过顶部的一个makefile.suite文件告诉编译系统“我在什么操作系统上跑”。进入解压后的根目录通常会看到一个类似makefile.suite的文件它就像整套工具编译的“总控面板”。tools子目录下的 Makefile 会去 include 这个总控文件所以你在tools目录里直接执行 make 时真正读取的编译参数可能来自上层目录。打开makefile.suite后最常见的需要确认的配置项是OS LINUX MACHINE LINUXOS告诉编译系统当前的操作系统类型MACHINE告诉编译系统当前的硬件/平台类型。把这两项都设置成LINUX对应 Linux x86_64 是最常见的默认配置。如果某些发行版默认没有设置或者你在 macOS 上编译就需要根据你看到的模板改成对应的值。这里我强调一下一定要检查不要认为官网发的包默认就一定能编译。有些版本默认值写的是OS LINUX但如果之前有人在同目录下改过编译参数或者 zip 解压时权限、换行符出了问题就会导致变量没被正确识别。最常见的现象是 make 时提示某个平台相关内容找不到或者把非 Linux 路径下的库引入进来。遇到这种问题先回makefile.suite找原因往往比在 makefile 里硬调更有效。3.2 官方源码的主目录结构与编译入口以 TPC-DS 官方工具包为例解压后的大致目录层次是这样的不同版本可能会略有差别TPC-DS_Tools_v3.2.0/ ├── makefile.suite ├── query_templates/ ├── specification/ ├── ETL/ └── tools/ ├── dsdgen.cpp ├── dsqgen.cpp ├── makefile ├── ...tools目录是编译的主战场。进入该目录后执行make即可触发编译。但我不建议第一次就直接傻乎乎地make因为如果编译失败你会看到满屏的 error 却不知道从哪看起。比较稳妥的做法是先把编译日志保存下来再快速定位错误cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools make clean make 21 | tee make.log为什么要make clean因为如果之前有人编译过、生成了旧的.o目标文件你修改了makefile.suite后这些旧文件可能不会自动全部重建造成一些非常“诡异”的链接报错。执行 clean 后再 make可以保证所有源码都按照新的参数重新编译。如果编译顺利你会在tools目录下看到新增的dsdgen和dsqgen两个可执行文件。有的版本还会生成tpcds.idx等数据处理文件这些文件是运行时配套的不要手滑删掉。3.3 make 过程中的实际输出怎么看很多人一看到编译输出就紧张觉得几十行 warning 就是有问题。其实 C 编译里的 warning 很常见像“未使用变量”“隐式类型转换”这类提示一般不影响工具使用。真正需要关注的是 error 级别的输出也就是以error:开头的内容。我编译时发现如果缺少 bison/flex报错通常会指向某个.y或.l文件并提示找不到yacc或lex。如果缺少 g会直接提示g: command not found。如果把OS或MACHINE改成了一组不存在的类型make 时则可能提示某个-D宏没有被定义甚至直接进入一个错误的编译分支。看到这些错误先对照第 2 节检查环境再回头检查 makefile.suite效率会高很多。如果 make 过程中出现了非常长的找不到标准库头文件的报错比如iostream: No such file or directory那基本可以确定编译工具链没装全或者当前环境中 C 标准库路径没配置好。此时不要盲目去修改源码先执行一下g --version确认 g 真实存在且版本可用再尝试用包管理器补齐libstdc-dev或g。3.4 编译产物确认与安装到统一目录make 成功后我建议先验证一下产物能不能正常执行cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools file dsdgen dsqgen ./dsdgen -helpfile命令能看到可执行文件的格式如果是 64 位 ELF说明编译出来的架构没问题。./dsdgen -help能打印出 dsdgen 支持的所有参数如果能看到那说明工具已经可以运行。很多人编译完就留在tools目录里用这样也没问题但如果后面还要生成多份数据集或者要把工具提供给其他测试同学使用更推荐把工具集中复制到一个独立目录比如/opt/tpc-ds/bin或者用户目录下的~/tools/tpc-ds/bin。mkdir -p /opt/tpc-ds/bin cp dsdgen dsqgen tpcds.idx /opt/tpc-ds/bin/注意这里我要提醒一句dsdgen运行时不光要靠可执行文件还需要tpcds.idx这类分布数据文件。如果你只拷贝了dsdgen和dsqgen运行时会提示找不到 DISTRIBUTIONS 文件。把tpcds.idx一起拷过去并把tools目录里的数据文件路径搞一致会省去很多麻烦。拷贝完成后可以把/opt/tpc-ds/bin加进PATH环境变量export PATH/opt/tpc-ds/bin:$PATH但注意这样只是当前终端生效后续重新登录会丢。如果希望长期生效可以写到.bashrc或/etc/profile.d/tpc-ds.sh中。这一步虽然不是编译本身但对后续压测工具使用体验影响很大。4. 编译成功不等于能用功能验证与数据生成流程4.1 先跑一个最小规模的数据生成任务工具编译完自然要实际生成一份测试数据验证一下。TPC-DS 的数据生成器dsdgen用一个叫SCALE的参数控制数据规模SCALE 1表示生成大约 1GB 的原始数据。之所以说“大约”是因为 TPC-DS 不是简单按行数线性扩展而是按每个表的目标规模比例放大最终总大小接近 1GB。在执行之前先建立一个数据输出目录例如mkdir -p /tmp/tpcds/data cd /tmp/tpcds/data然后回到tools目录执行cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/tools ./dsdgen -SCALE 1 -DISTRIBUTIONS ./tpcds.idx -DIR /tmp/tpcds/data这里有几个参数需要解释一下-SCALE 1数据规模倍率1 代表约 1GB。-DISTRIBUTIONS ./tpcds.idx指定分布数据文件路径。如果dsdgen和tpcds.idx在同一目录并且你在当前目录执行也可以省略但建议在脚本里显式写清楚避免路径对不上。-DIR /tmp/tpcds/data数据文件输出目录。这个命令运行几分钟后就能在/tmp/tpcds/data下看到很多.dat结尾的文件。比如日期表、商品表、销售表等。用wc -l可以简单看看每个文件行数wc -l /tmp/tpcds/data/*.dat | tail -5 head -3 /tmp/tpcds/data/store_sales.datSCALE 1的 store_sales 数据行数一般会在几十万到百万级别总文件看起来不大但对测试流程来说已经能跑通全链路了。我建议新手第一轮压测不要一上来就生成 10GB 或 100GB先用 1GB 验证工具稳不稳、目录路径对不对、文件格式是否符合预期。确认没问题后再根据被测数据库的实际容量和对标场景放大规模。4.2 用 dsqgen 生成真正的压测 SQL数据文件生成只是第一步。TPC-DS 的 99 条 SQL 并不是直接写死的值而是放在查询模板里。模板里有各种位置参数比如日期范围、类别编号、客户数量等需要运行dsqgen解析模板并替换成指定规模的随机参数才能生成可供数据库执行的 SQL。生成 SQL 前确认你已经进入解压后的根目录里的query_templates目录因为dsqgen需要指定模板文件所在的目录和模板列表。一个常见命令如下cd ~/tpc-ds/TPC-DS_Tools_v3.2.0/query_templates ../tools/dsqgen -DIRECTORY . \ -INPUT templates.lst \ -DIALECT netezza \ -OUTPUT_DIR /tmp/tpcds/queries先创建好/tmp/tpcds/queries目录。这里的-DIALECT netezza指的是“生成 SQL 的风格”。TPC-DS 的模板最初是为某一种特定 SQL 方言写的不同数据库在函数、类型转换、字符串语法上有细微差异dsqgen会根据 dialect 参数对模板内部的部分语法做替换。如果被测数据库不在官方支持的 dialect 列表里比较通用的办法是先生成 netezza 风格或直接参考你的数据库官方文档里推荐使用的 dialect。生成后打开几个 SQL 文件看看如果里面有特别数据库不支持的函数可以在导入阶段做统一替换或者在执行前用文本处理脚本过滤。很多数据库产品比如分析型数据仓库都已经兼容 PostgreSQL 或 MySQL 语法你可以按实际支持的语法做少量修正。4.3 如何判断生成的查询“能用”dsqgen执行完成后会在输出目录里生成一个或多个 SQL 文件。不少人看到文件生成就觉得万事大吉直接把整个 SQL 丢进数据库执行结果跑出来一片报错。这里我建议执行前先做两层验证。第一层是看 SQL 的规模对不对。用文本工具统计一下query_0.sql里包含多少个查询正常情况应当接近 99 个如果少了要检查模板列表是否完整。第二层是抽样执行。不要先跑全量而是从生成的文件中挑一个最简单的查询比如基于 date_dim、item 这类小表的查询先单条执行。这一步能快速发现 dialect 选择是否正确、字段名是否和实际表结构匹配。确认单条 SQL 能跑后再逐步增加查询条数最后才用并发或计时脚本跑完整 99 条。不要因为 SQL 是工具生成的就默认它一定能一次通过。4.4 完整的压测数据链路长什么样把数据文件和 SQL 文件都准备好后接下来就是压测工具真正发挥作用的阶段。常见做法是把.dat文件通过数据导入工具加载到被测数据库表中表结构和 TPC-DS 模型一致再把 SQL 文件里的查询依次执行或者使用一个外部脚本控制并发、记录耗时和正确性结果。如果你用的是 PostgreSQL 系数据库可以用COPY命令导入.dat文件。如果用的是其他分析型数据库通常也有对应的导入指令或者直接用官方提供的 ETL 脚本把文本文件转换为更适合批量加载的格式。这里有个容易踩的细节.dat文件里字段分隔符是竖线|不是逗号导入时记得指定分隔符否则所有字段会挤到第一列导致建表、校验全部错乱。我第一次用 psql 的\copy导入时忘了指定 delimiter结果生成了一大堆错误数据排查了很久才发现是这么低级的问题。5. 编译安装和初运行中的常见问题与排查思路5.1 编译阶段的典型报错对照表安装 TPC-DS 的过程中编译阶段的报错是最多的。我把实际见过的情况整理成了表格方便你在遇到类似问题时快速对照。报错现象大概率原因处理方式g: command not found没装 C 编译器安装gcc-c或build-essentialmake: command not found没装 make安装makelex/yacc 相关错误缺少 flex/bison安装flex bison后重新 make clean makeOS/MACHINE 相关问题makefile.suite 平台参数没配对编译前检查并设置OSLINUX、MACHINELINUXiostream: No such file or directoryg 缺失或 libstdc 开发包缺失补全编译工具链后重试undefined referencemake clean 没执行旧对象文件残留执行 make clean 后完整重新编译cannot find -lxxx某些静态库缺失根据报错中的库名搜索安装对应 dev 包这里想重点说下make clean的价值。TPC-DS 这类老 C 项目依赖关系和自动依赖生成并不算完善如果你第一次编译发现缺了 flex装好 flex 后直接再 make系统可能只重新编译部分文件导致“改了环境但没生效”的假象。最稳妥的做法始终是make clean make5.2 数据生成阶段的常见报错对照表编译通过只是第一步运行dsdgen和dsqgen时也有不少问题同样整理成速查表报错现象大概率原因处理方式DISTRIBUTIONS file not found没指定 tpcds.idx 路径加-DISTRIBUTIONS /path/tpcds.idx参数No space left on device数据规模超出磁盘空间清理磁盘或换更大目录Permission denied输出目录无写权限检查目录权限或改用有权限的路径无法打开输出文件-DIR指定目录不存在先 mkdir -p 输出目录Segmentation fault (core dumped)内存不足或二进制与系统不兼容减小 SCALE确认平台参数正确数据文件都是空文件dsdgen 当前目录缺少辅助文件在 tools 目录下运行或显式指定 DISTRIBUTIONS关于内存不足导致的段错误多说一句。虽然生成数据主要吃 CPU 和磁盘但某些向量数据和排序过程还是会占用较多内存。如果是低配虚拟机比如 2GB 内存还跑多个进程并行生成直接崩溃也不奇怪。建议第一轮只用单进程、小 SCALE 验证然后再考虑并行比如用-PARALLEL 2 -CHILD 1分别开两个进程。5.3 疑似环境问题时的系统化排查方法早期使用 TPC-DS 时环境问题很容易被误判为代码问题。比如在某个 Linux 发行版上编译通过但换一台机器执行时提示无法加载动态库或直接段错误多半不是写错了命令而是编译环境与运行环境差异太大。遇到这种情况我的排查顺序是这样的先确认执行环境架构uname -m排除 ARM 和 x86_64 混淆。再确认当前 shell 的 PATH 和动态库搜索路径echo $PATH、ldd ./dsdgen。查看可执行文件依赖了哪些系统库ldd dsdgen。如果动态库缺失优先补齐库文件如果库版本太低尽量在更干净或更新的系统上重新编译一次。在实际排障时ldd是非常好用的工具它能直接告诉你编译出来的二进制需要哪些.so文件。如果某个库显示not found那这个工具拿到其他机器上大概率也会运行失败。与其到处拷贝缺失库不如就直接在目标机器或同版本系统上重新编译这种“土办法”反而更稳。5.4 编译期间的日志也要学会保存我见过很多同学卡在编译错误上第一反应是把错误截个图下来但看不到上面几百行里更早的 error。正确做法是在第一次触发编译时就顺手把完整日志存下来make 21 | tee /tmp/tpcds_make.log这样不仅方便你自己搜索报错点还能在向别人提问时给出完整上下文。日志里有时候能看到多个 error但真正的根因往往是最前面那一个后面的 error 可能只是前面错误的连带反应。比如头文件找不到后面几百行未定义标识符的报错其实都不需要看修复头文件路径后它们会一起消失。6. 关于后续使用的一些实用建议和踩坑体会把 TPC-DS 编译安装这件事说清楚之后我还想聊一些后续真正做压测时会用到的经验。很多文章只写到能生成数据就结束了但实际把工具集成进测试流程后你会遇到比编译安装更多的问题。第一优先用脚本统一封装命令不要每次手工敲。TPC-DS 的dsdgen参数并不复杂但一旦涉及并行生成、多规模数据集手工敲会很容易漏参数或把不同规模的数据混在同一目录里。我在实际使用中会为不同 SCALE 值分别建目录比如data_1/、data_100/、data_1000/然后写一个简单的 shell 脚本把数据生成和 SQL 生成两个步骤串起来SCALE${1:-1} mkdir -p /tmp/tpcds/data_$SCALE cd /opt/tpc-ds ./dsdgen -SCALE $SCALE -DISTRIBUTIONS ./tpcds.idx -DIR /tmp/tpcds/data_$SCALE这样重复跑同一规模数据时只需要改一个变量不容易出线路径混乱。第二不要光记官方命令不记版本。TPC-DS 不同版本之间生成的模板、表结构、查询数量可能都有差异。如果你要对比两个数据库最好使用同一个版本的工具包和同一规模的 SCALE否则测试结论很难让听的人信服。第三数据生成是可以并行的但并行后文件会被切分成多个分片导入数据库前需要把分片合并或让数据库并行加载工具识别分片。实际导入时要注意这样会占用大量 IO建议在目标数据库磁盘压力较低的时候执行避免把压测环境搞成 IO 阻塞。我自己在做这套工具时最大的体会是“编译安装只是入场券真正难的是把数据、查询、数据库三者的边界理清楚”。如果你第一次编译 TPC-DS 时报错不用慌大部分问题都出在环境缺依赖或者平台参数没配对。按make clean make、补依赖、查 DISTRIBUTIONS 路径这条路走下来基本都能过。最后再分享一个小技巧把编译好的二进制连同tpcds.idx、查询模板和 templates.lst 整份放到一个单独的目录不要每次临时去解压包翻。这样后面不管谁要用只要把这个目录拷走再配好 PATH 就能直接用。对于长期做数据库压测的团队来说这套“干净的环境目录”能节省很多重复试错的时间。