Used: 438105027512, Limit: 438103947386. Mem usage has exceed the limit of single query, You can change the limit by set session variable exec_mem_limit目前我设置比较这个限制的值大,还是报错超出限制,

我们这边我需要看一下,现在除了调整数据顺序,其他没有更合适的方案了吗

昨天您帮忙拉会讨论的sql 目前有结论了吗

两个我都改一版不用调字段顺序的吧。明天才能给您。
那个SQL没有修改参数就能解决的方案,需要数据和表结构结合来解决。

10t-h-final.txt (18.1 KB)

10tds第三版本-final.txt (33.3 KB)

辛苦您了,我们在测试一下

您这个设计建表语句lineitem和order 应该是有问题,您那边是测试过了吗,我记的分组join的话,两个表的排序键个数应该保持一致,


同一 CG 内的表的分桶键的类型、数量和顺序完全一致,并且桶数一致,从而保证多张表的数据分片能够一一对应地进行分布控制。分桶键,即在建表语句中 DISTRIBUTED BY HASH(col1, col2, ...) 中指定一组列。分桶键决定了一张表的数据通过哪些列的值进行 Hash 划分到不同的 Bucket Seq 下。同 CG 的表的分桶键的名字可以不相同,分桶列的定义在建表语句中的出现次序可以不一致,但是在 DISTRIBUTED BY HASH(col1, col2, ...) 的对应数据类型的顺序要完全一致。
请参考约束

目前我们是10台64 核数 512G 的,我们是不是拆成15台32核数256 会比较好呢

因为是mpp架构,节点越多,性能越好。

因为我们咱们最新的建表语句建完之后发现还是解决不了 hash join 问题,我想得是加机器来解决

MySQL [tcph10tmp]> 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 ‘1994-01-01’ + interval ‘1’ year
-> group by n_name
-> order by revenue desc;
ERROR 1064 (HY000): row count of right table in hash join > 4294967295

colocate join DUPLICATE KEY的顺序和键没有什么关系的,主要是DISTRIBUTED BY HASH 的数据类型和BUCKETS要一致。

我测试一下 稍等

1赞

我已经建好了,导入一下数据测试下,麻烦您了

请稍等,不要导入数据,有点问题

嗯嗯好的没事,麻烦您了

10tds第三版本-final.txt (33.2 KB) 10t-h-final.txt (18.0 KB)
让您久等了,经过测试,可以了。

经过千锤百炼才是更好的,谢谢您

数据在导入中了,导入完了测试结果给您反馈

辛苦您们测试多次,有问题请及时反馈,谢谢!