检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
检测到您已登录华为云国际站账号，为了您更好的体验，建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
应用场景 交易型应用 大并发、大数据量、以联机事务处理为主的交易型应用，如政务、金融、电商、O2O、电信CRM/计费等，服务能力支持高扩展、弹性扩缩，应用可按需选择不同的部署规模。 详单查询 具备PB级数据负载能力，通过内存分析技术满足海量数据边入库边查询要求，适用于安全、电信、金融、物联网等行业的详单查询业务。
则执行计划将存在“Streaming”，导致DN之间存在较大通信数据量，如图1所示。 图1 选择合适的分布列案例（一） 如果将a作为t1的分布列，将b作为t2的分布列： 1 2 CREATE TABLE t1 (a int, b int) DISTRIBUTE BY HASH (a);
出HashJoin在不同的DN上存在严重的计算偏斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的偏斜。 优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan
据重分布的代价且单个节点的算力完全够用所以可以得到性能的提升。对于大数据量的计算，多节点并行计算更有优势。需要通过打开关闭开关来对比哪种情况更快（dngather_min_rows默认为500行，下述案例采用了默认值）。下面简单说明几个案例： 案例环境准备 为了便于案例演示，需准备建表语句如下：
向量距离计算接口 l2_distance 功能说明：计算两个向量的欧式距离。 入参1的类型：floatvector 入参2的类型：floatvector 出参类型：float8 代码示例： gaussdb=# SELECT l2_distance(floatvector('[1,2
出HashJoin在不同的DN上存在严重的计算偏斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的偏斜。 优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan
出HashJoin在不同的DN上存在严重的计算倾斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的倾斜。 优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan
案例：使用DN Gather减少计划中的Stream节点 DN Gather用来把分布式计划中的Stream节点去掉，把数据发送到一个节点进行计算，这样可以减少分布式计划执行时数据重分布的代价，从而提升单个查询效率以及系统整体的吞吐能力。不过DN Gather面向的是TP的小数据
案例：调整基于代价的查询重写GUC参数costbased_rewrite_rule 查询重写能让优化器选择不同的执行路径，但部分规则对SQL的改写，并不能确保输出后的都是可以提升性能的计划。一旦改写错误可能导致千倍的性能差距，因此在查询改写阶段需要对此类规则支持基于代价的评估策略
案例：调整基于代价的查询重写GUC参数costbased_rewrite_rule 查询重写能让优化器选择不同的执行路径，但部分规则对SQL的改写，并不能确保输出后的都是可以提升性能的计划。一旦改写错误可能导致千倍的性能差距，因此在查询改写阶段需要对此类规则支持基于代价的评估策略
GaussDB实例内存使用率指标的计算方法 GaussDB内存使用率指标的计算方法： 内存使用率 =（总内存 –（空闲内存 + 给文件的缓冲大小 + 高速缓冲存储器使用的大小））/ 总内存 父主题： 数据库监控
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 --建表 CREATE TABLE staffs (staff_id NUMBER(6)
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 --建表 CREATE TABLE staffs (staff_id NUMBER(6)
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 --建表。 CREATE TABLE staffs (staff_id
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 --建表 CREATE TABLE staffs (staff_id NUMBER(6)
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 --建表 CREATE TABLE staffs (staff_id NUMBER(6)
案例：建立合适的索引 现象描述 查询与销售部所有员工的信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 --建表 CREATE TABLE staffs (staff_id NUMBER(6)
通常优化器总会选择最优的执行计划，但是代价估算，尤其是中间结果集的代价估算一般会有比较大的偏差，这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan进行agg计算模型的干预。 一般来说，当agg汇聚的收敛度很小时，即结果集的个数在agg之
通常优化器总会选择最优的执行计划，但是众所周知代价估算，尤其是中间结果集的代价估算一般会有比较大的偏差，这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan进行agg计算模型的干预。 一般来说，当agg汇聚的收敛度很小时，即结果集的个数在ag
通常优化器总会选择最优的执行计划，但是众所周知代价估算，尤其是中间结果集的代价估算一般会有比较大的偏差，这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan进行agg计算模型的干预。 一般来说，当agg汇聚的收敛度很小时，即结果集的个数在ag
长按/截图保存，微信识别二维码
或者关注公众号“华为云”
