GBase 8a数据库实战案例之——大表JOIN性能调优讲解

在日常运维和开发中你是否遇到过这样的场景一条原本跑得好好的SQL随着数据量增长突然从秒级响应变成了分钟级等待或者在搭建数据仓库时面对从其他商业数据库迁移过来的海量数据感到无从下手今天我们不讲空泛的概念直接上硬菜分享南大通用GBase 8a MPP Clustergbase database的实战案例大表JOIN性能调优。大表JOIN是分析型数据库中另一大性能杀手。根据项目实战经验当遇到大表JOIN慢时可以按以下“心法”排查1、先看“数据分布”是否对齐这是最容易被忽略的一点。如果JOIN的两张表分布键不一致GBase 8a必须执行Redistribute操作数据重分布这是极大的网络开销。优化建议 优先确保高频JOIN的条件字段是分布键。对于数据量不大且经常关联的维表建议创建为复制表REPLICATED这样在每个节点都有完整副本JOIN时无需跨节点传输数据。2、再看“过滤条件”是否下推在分布式数据库中“先过滤后关联”是铁律。如果在大表JOIN前没有通过WHERE条件把数据量降下来大量的无效数据就会参与Shuffle。优化建议 尽量在JOIN之前的子查询或CTE公共表表达式中提前加上时间、状态等过滤条件。开启CTE支持需配置参数 _t_gcluster_support_cte 1。3、善用“物化视图”预计算对于频繁执行的复杂聚合报表每次都现场计算并不划算。南大通用GBase 8a数据库支持物化视图Materialized View可以把预先计算好的结果存储起来查询时直接读取效率极高。注意 目前GBase 8a的物化视图刷新是全量刷新建议在业务低峰期执行。