SQL一多就慢 ? 了解下GaussDB(DWS)中SQL查询计划的stream机制
【摘要】 分布式数据库理想的运行状态就是 在多个表JOIN的时候，每两个表间的JOIN 都是在本地数据节点上做 join, 而不用重新分布，重分布会带来很大的网络开销， 一旦并发较高的时候，就会出现线程，网络或I/O瓶颈 (比如CBG某平台集群体现为大量线程启动停止申请释放内存及网络卡顿， EBG某集群体现为网络和I/O瓶颈 ) ， 当然如果您的SQL是点查，没有表的JOIN (或简单J...
分布式数据库理想的运行状态就是 在多个表JOIN的时候，每两个表间的JOIN 都是在本地数据节点上做 join, 而不用重新分布，重分布会带来很大的网络开销， 一旦并发较高的时候，就会出现线程，网络或I/O瓶颈 (比如CBG某平台集群体现为大量线程启动停止申请释放内存及网络卡顿， EBG某集群体现为网络和I/O瓶颈 ) ， 当然如果您的SQL是点查，没有表的JOIN (或简单JOIN, 都能本地关联，无需重分布) ， 且都有较好的索引， 那和传统数据库(比如Oracle)的并发就没有太大差异了 (但是作为数仓产品，这毕竟是少数场景了) 。
希望通过stream原理上的了解，在定义表及编写SQL的时候，能充分考虑到 stream 可能发生的场景，尽量减少 stream 的产生， 让SQL更接近分布式数据库的理想状态运行 ，减少异常的发生 。 如果您的SQL执行计划中含有 "Streaming" 关键字超过50 (其实建议是越低越好) ， 这个SQL的并发可能会上不去，且可能单个运行时很快，几个类似SQL一起执行性能就会下降比较明显，甚至出现阻塞排队 。
Stream过多对于ms级的查询的稳定性影响很大，要尽最大可能消减 。813或以上版本可以通过 max_streams_per_query =50 或其他值来限制SQL的stream。
目前降低stream可以参考以下三种方式整改：
1. 针对异常SQL中的小表整改成复制表 (不建议无根据全部小表整改为复制表) , 整改方法： alter table xxx distribute by replication (注意闲时变更进行 ) 。
2. 检查分布列是否合理，常用的join列是否为分布列。
3. 带with的语句，升级到813后可以通过share scan减少stream数量。
4. 大量uinon 的查询，建议减少SQL中 union个数 。
注意： hash表改复制表，有很多需要注意的地方，比如有些表使用了 uuid 作为之前的 hash 分布列 或 作为PK 列，在改为复制表后，由于复制表需要保证所有节点的数据一致， uuid 下推无法保障数据一致， 只能在CN节点先生成再下发DN , 导致了复制表中包含 uuid 生成的函数就会出现不下推现象 ，不下推会导致 insert 操作一笔笔插入（即使是批量写入也会转换为一笔笔写入），出现小CU膨胀，影响写入和后续查询性能。 可能的方案是 ： 不再使用 uuid 等导致不下推的函数 。
作为开发人员，如何在开发阶段识别Streaming算子大于50的SQL ：
explain verbose 后面接SQL 语句， 查看执行计划，统计执行计划中的"Streaming" 字样个数，除以2就是这个SQL包括的Streaming算子。
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）