gbase_buffer_result参数

名称：gbase_buffer_result

含义：这个参数用于配置物化结果集BUFFER 大小。当查询结果集超过gbase_buffer_result 的大小时，会在cache 目录中产生格式为GB_CB_XX...XX.express_tmp 的临时文件来缓存结果集数据。该参数与gbase_buffer_rowset 的不同之处在于，gbase_buffer_rowset控制的是查询过程中，中间运算结果物化时使用的BUFFER 大小，而gbase_buffer_result 是为最终查询结果物化时使用的BUFFER 大小。

作用范围：session级

取值范围：无

默认值：200M(虚拟机)

推荐值：如果不进行频繁的join拉表查询，此数值默认系统自己设置即可，否则需要对这个值有一个设定，但是具体也需要看参与的表的大小，目前虚机中自动设置为总内存的1/5，可以作为参考

参数设置方法及效果演示

（1）测试版本

SUSE11_build11.4_r36 GBase 8.5.1.2 build 39017

（2）设置参数

gbase> show variables like   '%gbase_buffer_result%';

+---------------------+-----------+

| Variable_name       | Value     |

+---------------------+-----------+

| gbase_buffer_result | 209715200 |

+---------------------+-----------+

1 row in set (Elapsed: 00:00:00.00)

确认当前大小为200M

gbase> select 209715200/1024/1024 from dual;

+---------------------+

| 209715200/1024/1024 |

+---------------------+

|        200.00000000 |

+---------------------+

1 row in set (Elapsed: 00:00:00.00)

随后，将两张拥有60W和3000W记录的表进行join，查看是否产生临时文件：

稳定起见，跑了3次，每次时间均不一致，但是后两次比较平均；

对两个表进行join测试：

gbase> select a.p_partkey,sum(a.p_size) from part a left join lineorder b on a.p_partkey=b.lo_orderkey where a.p_size<6 group by a.p_partkey;

|    599950 |            45 |

|    599982 |            36 |

+-----------+---------------+

60083 rows in set (Elapsed: 00:01:03.34)

|    599913 |            18 |
|    599961 |            45 |
+-----------+---------------+
60083 rows in set (Elapsed: 00:00:46.06)

|    599915 |            36 |
|    599989 |            18 |
+-----------+---------------+
60083 rows in set (Elapsed: 00:00:45.87)

此时查看是否有临时文件，并没有发现：
SMPP1:/opt # find / -name *.express_tmp*

变更参数大小：发现此参数变更需要加global
gbase> set gbase_buffer_result=1048576;
ERROR 1229 (HY000): Variable 'gbase_buffer_result' is a GLOBAL variable and should be set with SET GLOBAL
gbase> set global gbase_buffer_result=1048576;
Query OK, 0 rows affected (Elapsed: 00:00:00.03)
查看是否变化：
gbase> show variables like '%gbase_buffer_result%';
+---------------------+---------+
| Variable_name       | Value   |
+---------------------+---------+
| gbase_buffer_result | 1048576 |
+---------------------+---------+
1 row in set (Elapsed: 00:00:00.00)
重新进行join查询：
gbase> select a.p_partkey,sum(a.p_size) from part a left join lineorder b on a.p_partkey=b.lo_orderkey where a.p_size<6 group by a.p_partkey;

同时，查看是否有临时文件：
SMPP1:/opt # find / -name *.express_tmp*
/opt/gnode/tmpdata/cache_gbase/GB_MAT00000067C28D80x2bc3540.express_tmp
发现临时文件
SMPP1:/opt/gnode/tmpdata/cache_gbase # ll
total 8208
-rw-rw---- 1 gbase gbase 8388608 Jun 15 16:29     GB_MAT00000010C03170x2bc3540.express_tmp
drwxrwx--x 3 gbase gbase    4096 Jun 15 15:51 tmp_materialized

将参数调整会200M，再次进行测试：
gbase> select a.p_partkey,sum(a.p_size) from part a left join lineorder b on a.p_partkey=b.lo_orderkey where a.p_size<6 group by a.p_partkey;

查看临时文件：
SMPP1:/opt/gnode/tmpdata/cache_gbase # ll
total 4
drwxrwx--x 3 gbase gbase 4096 Jun 15 15:51 tmp_materialized
恢复之后，临时文件消失了
由此看出，此参数如果不能满足要求，则会占用磁盘空间，IO性能收到影响，因此在调优的时候要考虑业务场景，如果频繁join等查询操作，且要查询的结果集很大，那么可以适当的调整此参数