TPC-H是一个广泛使用的基准测试，用于评估数据库系统在决策支持系统（DSS）场景下的性能。
在昨天的文章中，我们完成了《Oracle 23ai TPC-H 测试环境部署》，本文将继续记录在未做任何优化场景下，这22条SQL的真实执行情况。
- 1.修订执行有问题的SQL
- 2.完整运行22个SQL
- 3.测试结果统计（未做任何优化场景）
1. 修订执行有问题的SQL
因为根据《Oracle 23ai TPC-H 测试环境部署》准备好的TPC-H环境，实际测试发现有5个SQL需要微调下，否则执行会报错。
但不必担心，都是比较小的问题，不需要大改，主要是不符合Oracle 特殊的语法规则，稍加修改即可：
- Oracle 不允许在子查询别名前使用
AS关键字 - Oracle 子查询的别名后面不需要也不能跟列名列表，只需要在子查询的末尾直接写上别名
- Oracle 不支持 substring(c_phone from 1 for 2) 函数的这种语法
实际测试涉及到的具体SQL和改写方案参考：
query7.sql、query8.sql、query9.sql
- 删除报错位置的
AS关键字，具体位置如果找不到可以执行下，会报错具体位置，删除报错位置的AS关键字即可。
query13.sql
- 删除报错位置的
AS关键字 - 把别名后面指定的
(c_custkey,c_count)列名都去掉，列名别名c_count直接在子查询中直接指定即可。
query22.sql
- 删除报错位置的
AS关键字 - 将
substring(c_phone from 1 for 2)改写为：substr(c_phone, 1, 2)，共有三处。
其他优化（可选）：
如果文件尾部有多余的where rownum语句，可以快速去掉，避免测试中不必要的错误回显：
查询最后一行情况：tail -n 1 query*.sql
我这里去掉文件最后一行：sed -i '$d' query*.sql
2. 完整运行22个SQL
我需要记录在做任何优化之前，确保完整运行过TPC-H的22个SQL查询，并记录每个查询的执行时间。
我这里使用如下脚本 query_all.sh 测试：
vi query_all.sh
bash
for i in {1..22}; do
echo "PROMPT 当前执行第 $i 个查询;" >> commands.sql
echo "@query$i" >> commands.sql
done
sqlplus -s tpch/tpch@alfred @commands.sql > output.log 2>&1因为执行时间比较长，我这里选择放到后台执行，同时可以利用周末的时间：
bash
nohup sh query_all.sh &后台执行完成之后，发现这个output.log有811M大小..
嗯，有些查询返回行数实在是太多了，先不管，直接过滤下执行时间显示：
bash
[oracle@dbtest dbgen]$ grep "Elapsed:" output.log
Elapsed: 00:06:36.20
Elapsed: 00:01:09.51
Elapsed: 00:07:43.89
Elapsed: 00:07:24.58
Elapsed: 00:08:11.85
Elapsed: 00:06:01.30
Elapsed: 00:07:39.31
Elapsed: 00:07:46.35
Elapsed: 00:10:10.19
Elapsed: 00:08:45.04
Elapsed: 00:00:56.25
Elapsed: 00:07:04.59
Elapsed: 00:02:46.57
Elapsed: 00:06:22.81
Elapsed: 00:00:00.06
Elapsed: 00:06:09.22
Elapsed: 00:00:00.38
Elapsed: 00:01:11.31
Elapsed: 00:06:20.15
Elapsed: 00:17:00.94
Elapsed: 00:07:05.97
Elapsed: 00:07:15.76
Elapsed: 00:14:26.95
Elapsed: 00:01:22.08这有点乱。。而且咋是24个？比22个SQL要多了两个？
这里使用到一个小技巧，在匹配到关键字的行之后，额外多显示后面 1 行内容：
bash
grep -A 1 "Elapsed:" output.log这样显示结果就是这样，第一个Elapsed时间就是对应第1个查询，后面也都好找到一一对应了，方便判断，原来执行第 15 个查询，是存在先创建视图，再查询，再删除这个视图的逻辑，所以Elapsed会多了两个，去掉这两个时间干扰即可。
3.测试结果统计（未做任何优化场景）
这里让鲸鱼小助手帮我根据实际测试结果直接整理出表格，方便大家直观看到测试结果。
查询执行时间统计表
| 查询编号 | 执行时间 (HH:MM:SS) | 执行时间 (秒) | 执行快慢排名 |
|---|---|---|---|
| 11 | 00:00:56.25 | 56.25 | 1 |
| 2 | 00:01:09.51 | 69.51 | 2 |
| 16 | 00:01:11.31 | 71.31 | 3 |
| 22 | 00:01:22.08 | 82.08 | 4 |
| 13 | 00:02:46.57 | 166.57 | 5 |
| 15 | 00:06:09.22 | 369.22 | 6 |
| 6 | 00:06:01.30 | 361.30 | 7 |
| 17 | 00:06:20.15 | 380.15 | 8 |
| 14 | 00:06:22.81 | 382.81 | 9 |
| 1 | 00:06:36.20 | 396.20 | 10 |
| 12 | 00:07:04.59 | 424.59 | 11 |
| 19 | 00:07:05.97 | 425.97 | 12 |
| 20 | 00:07:15.76 | 435.76 | 13 |
| 4 | 00:07:24.58 | 444.58 | 14 |
| 7 | 00:07:39.31 | 459.31 | 15 |
| 3 | 00:07:43.89 | 463.89 | 16 |
| 8 | 00:07:46.35 | 466.35 | 17 |
| 5 | 00:08:11.85 | 491.85 | 18 |
| 10 | 00:08:45.04 | 525.04 | 19 |
| 9 | 00:10:10.19 | 610.19 | 20 |
| 21 | 00:14:26.95 | 866.95 | 21 |
| 18 | 00:17:00.94 | 1020.94 | 22 |
TOP 5 慢 SQL 执行情况
| 查询编号 | 执行时间 (HH:MM:SS) | 执行时间 (秒) | 执行快慢排名 |
|---|---|---|---|
| 18 | 00:17:00.94 | 1020.94 | 22 |
| 21 | 00:14:26.95 | 866.95 | 21 |
| 9 | 00:10:10.19 | 610.19 | 20 |
| 10 | 00:08:45.04 | 525.04 | 19 |
| 5 | 00:08:11.85 | 491.85 | 18 |
关键信息
- 最慢查询 ：
- 查询编号 18 ，执行时间 1020.94 秒 （约 17 分钟），排名第 22。
- 第二慢查询 ：
- 查询编号 21 ，执行时间 866.95 秒 （约 14 分 27 秒），排名第 21。
- 第三慢查询 ：
- 查询编号 9 ，执行时间 610.19 秒 （约 10 分 10 秒），排名第 20。
- 第四慢查询 ：
- 查询编号 10 ，执行时间 525.04 秒 （约 8 分 45 秒），排名第 19。
- 第五慢查询 ：
- 查询编号 5 ，执行时间 491.85 秒 （约 8 分 12 秒），排名第 18。
说明
- 执行快慢排名 是根据执行时间（秒）从小到大排序，排名越小表示查询越快，排名越大表示查询越慢。
- 以上 TOP 5 慢 SQL 的执行时间均超过 8 分钟 ，其中查询编号 18 和 21 的执行时间尤为突出，分别超过 17 分钟 和 14 分钟。
- 这些慢 SQL 可能需要进一步优化，例如检查索引、优化查询逻辑或调整数据库配置，以提升整体性能。
在后续文章中我们将开始优化这些SQL，欢迎关注。