- 综合排序
- 最热优先
- 最新优先
- 来自专栏大数据&分布式
Hive CBO优化剖析
Parser：将HiveSQL语句基于ANTLR4编译解析为AST抽象语法树 ASTNode； Semantic Analyzer：基于SemanticAnalyzer#genResolvedParseTree 基于Operator转为Task，基于物理计划树(算子树) 实现物理优化 CBO优化 实现原理 Hive使用HiveVolcanoPlanner 继承原生的Calcite VolcanoPlanner Hive基于CBO优化的解析数据对象流转如下所示： Hive CBO实现内核：在QB转Operator逻辑计划时进行扩展处理，QB → Calcite CBO优化 → Operator。 本文通过背景介绍、解析流程、CBO优化三部分详述Hive CBO原理。Hive SQL核心解析流程包括解析、语义分析、逻辑优化、物理优化步骤。 Hive CBO优化依赖Calcite 火山模型优化器实现，本文介绍了相关的CBO实现原理，CBO统计元数据和ANALYZE执行实现。 我正在参与2024腾讯技术创作特训营最新征文，快来和我瓜分大奖！
89962编辑于 2024-04-27 - 来自专栏mazhen.tech
基于代价优化（CBO）实现代码导读
CBO的整体思路是：从逻辑查询计划树，自上而下枚举每个逻辑运算符可能的物理算子，从所有可能的执行路径中选择一条评估代价最小的作为物理查询计划。 CBO核心流程的代码在plan/optimizer.go中的physicalOptimize： func physicalOptimize(logic LogicalPlan) (PhysicalPlan
30210编辑于 2023-11-24 - 来自专栏about云
Apache Spark 2.2中基于成本的优化器（CBO）
问题导读 1.什么是CBO,RBO? 2.什么是执行计划？ 3.什么是join，filter？ 4.事实表和维度表的区别？ Spark的基于成本的优化器（CBO）并讨论Spark是如何收集并存储这些数据、优化查询，并在压力测试查询中展示所带来的性能影响。 CBO依赖细节化的统计信息来优化查询计划。要收集这些统计信息，用户可以使用以下这些新的SQL命令： [AppleScript] 纯文本查看 复制代码 ? 总之，关闭CBO,查询花费了241秒。 使用了CBO的Q25 另一方面，用了CBO,Spark创建了优化方案可以减小中间结果（如下）。在该案例中，Spark创建了浓密树而不是左-深度树。 这是因为使用或没使用CBO的查询计划没有不同 (例如，即使没有CBO, Spark’s Catalyst 优化器的柱状图也可以优化这些查询。
2.5K70发布于 2018-03-26 - 来自专栏老虎刘谈oracle性能优化
CBO规则下的优化器还是要按规则办事
另外, like 'xxxxx%' 也用不了降序索引. test case2: with as写法 有些人把with as 的写法当成了SQL优化的方法,好像用了这个语法就能让SQL效率提高, 下面这个案例是把一个复杂的生产案例做了简化 tmp where object_id=100 union all select count(*) from tmp where object_id=200; 上面SQL, 因为tmp被使用了两次, 被优化器自动做了 上面两个案例我认为优化器应该能够做出最好的选择, 实际并不如我们想象的那么美好. oracle数据库有公认的最强大的优化器, 强大如此, 也有一些可以改进的地方. oracle 的优化器是CBO (costed
52930编辑于 2022-06-27 - 来自专栏大数据架构
Spark SQL 性能优化再进一步 CBO 基于代价的优化
它属于 LogicalPlan 的优化，所有优化均基于 LogicalPlan 本身的特点，未考虑数据本身的特点，也未考虑算子本身的代价。 可计算出指定列的统计信息 ANALYZE TABLE table_name COMPUTE STATISTICS FOR COLUMNS [column1] [,column2] [,column3] [,column4] 优化多表 Join 顺序 未开启 CBO 时，Spark SQL 按 SQL 中 join 顺序进行 Join。极端情况下，整个 Join 可能是 left-deep tree。 开启 CBO 后， Spark SQL 将执行计划优化如下 ? 优化后的 Join 有如下优势，因此执行时间降至 71 秒 Join 树不再是 left-deep tree，因此 Join 3 与 Join 4 可并行进行，Join 5 与 Join 6 可并行进行
1.2K30发布于 2018-10-10 - 来自专栏大数据架构
Spark SQL 性能优化再进一步 CBO 基于代价的优化
它属于 LogicalPlan 的优化，所有优化均基于 LogicalPlan 本身的特点，未考虑数据本身的特点，也未考虑算子本身的代价。 更适合本例 [Spark SQL build side with CBO] 优化 Join 类型 在 Spark SQL 中，Join 可分为 Shuffle based Join 和 BroadcastJoin [Spark SQL join type selection with CBO] 优化多表 Join 顺序 未开启 CBO 时，Spark SQL 按 SQL 中 join 顺序进行 Join。 后， Spark SQL 将执行计划优化如下 [Spark SQL multi join reorder with CBO] 优化后的 Join 有如下优势，因此执行时间降至 71 秒 Join 树不再是 RBO Spark SQL 性能优化再进一步 CBO 基于代价的优化 Spark CommitCoordinator 保证数据一致性 Spark 灰度发布在十万级节点上的成功实践 CI CD
1.6K30发布于 2018-10-09 - 来自专栏BigDataplus
Hive优化器原理与源码解析系列—CBO成本模型CostModel(一)
但除了MapReduce和Tez外，其他引擎都有自己优化器实现。 优化器在用户HiveConf配置的引擎信息，来使用不同的成本模型。 优化器的成本模型CostModel设计的是否完善、是否科学直接决定着CBO优化器计算构建出执行计划plan是否准确，同样Hive优化器根据CostMode也是基于Hive Operator Tree操作树中节点 = hive.cbo.costmodel.cpu，依次类推）： CPU成本 = HiveConf.ConfVars.HIVE_CBO_COST_MODEL_CPU 网络成本 = CPU成本 * HiveConf.ConfVars.HIVE_CBO_COST_MODEL_NET 在这里来确定Join 算法可减少优化器的搜索空间，提高效率。
1.8K30编辑于 2022-04-25 - 来自专栏大数据&分布式
Spark CBO统计元数据
解析流程 Spark SQL解析流程概述为： SQL语句基于ANTLR4编译解析成AST树，SparkSqlParser#parse通过Visitor访问者模式遍历解析AST树，生成Unresolved Logical Plan(未解析逻辑计划)； 基于Analyzer#apply规则的匹配作用，绑定树节点信息(元数据Catalog)后生成Logical Plan(逻辑计划)； 基于Optimizer#apply优化低效的逻辑树结构 ，生成Optimized Logical Plan(优化逻辑计划)； 基于SparkPlanner#plan，根据Optimized Logical Plan匹配对应的Strategy并生成一组Physical 统计信息 Spark 2.2 开始支持CBO优化，触发统计元数据更新的时机如下： ANALYZE：AnalyzeTableCommand、AnalyzeColumnCommand； ALTER：AlterTableAddPartitionCommand
71296编辑于 2025-03-20 - 来自专栏沃趣科技
SQL优化案例-改变那些CBO无能为力的执行计划
用户写的sql，Oracle会进行等价改写，即使是RBO优化模式，Oracle也会给你做一些转换，这些转化都是基于一种固定的算法，oracle称这种转换是“启发式”的。 网上有很多优化法则，有的说exists比in效率高，有的说in比exists执行的快，那就要看SQL是如何写的，CBO是如何转换的，是否能转换？当然这种转换不是基于成本的而是“基于启发的转化”。 当Oracle没办法做transformation的时候，可能就是sql产生问题的时候，此时就要我们去找原因了，下面通过一些案例，说明这种优化器无能为力的情况（为了保护客户的隐私，表名和部分列已经重命名 A.OPENCUPDATE+365=TO_DATE('2018-04-27','YYYY-MM-DD') THEN A.CUSTNO END YE, '2' AS QD, SUBSTR(B.OPENBANKNO,1,4) then A.CUSTNO END BQXZ, CASE WHEN c.khh is null then A.CUSTNO END ye, '2' AS QD, SUBSTR(B.OPENBANKNO,1,4)
1.2K70发布于 2018-05-15 - 来自专栏BigDataplus
Hive优化器原理与源码解析系列—CBO成本模型CostModel(二)
Hive优化器原理与源码解析系列—CBO成本模型CostModel(一) 这篇文章是关于Tez引擎的CostModel成本模型：HiveTezCostModel Tez引擎的成本模型，相对比较完善， SMB Join SMB Join又称Sort Merge Bucket Join，是对上述Bucket Map Join关联算法的优化，如果要Join的数据已按Join key排序的，则避免创建哈希表 ; final double ioCost = algoUtils.computeSortMergeIOCost(relationInfos);//计算Sort Merge 的IO成本 // 4. final double ioCost = algoUtils.computeMapJoinIOCost(relationInfos, streaming, parallelism); // 4. 相对于MR引擎的默认成本模型要完善了很多，越准确的成本模型越有利于CBO构建出越优化的执行计划。
82020编辑于 2022-04-25 - 来自专栏数栈技术分享
袋鼠云数栈基于CBO在Spark SQL优化上的探索
原文链接：袋鼠云数栈基于 CBO 在 Spark SQL 优化上的探索 一、Spark SQL CBO 选型背景 Spark SQL 的优化器有两种优化方式：一种是基于规则的优化方式 (Rule-Based 2、CBO 是 RBO 改进演化的优化方式 CBO 是对 RBO 改进演化的优化方式，它能根据优化规则对关系表达式进行转换，生成多个执行计划，在根据统计信息 (Statistics) 和代价模型 (Cost ● CBO 优化例子 而使用 CBO 优化器得到的执行计划图如下： 我们不难看出，CBO 优化器充分考虑到中间结果，感知到中间结果的变化满足能 Broadcast Join 的条件，所以生成的最终执行计划会选择 四、未来展望 在 CBO 优化方面持续投入研究后，Spark SQL CBO 整体相比较 RBO 而言已经有了很大的性能提升。 AQE 是动态 CBO 的优化方式，是在 CBO 基础上对 SQL 优化技术又一次的性能提升。
1.6K20编辑于 2022-06-10 - 来自专栏大数据&分布式
Presto CBO统计元数据
ConnectorMetadata#getTableStatistics获取元数据信息，目前仅Hive Connector、Iceberg Connector支持获取元数据的统计信息，统计信息用于树节点Visitor遍历时进行CBO 优化。 ConnectorMetadata#getTableStatistics获取元数据信息，目前仅Hive Connector、Iceberg Connector支持获取元数据的统计信息，统计信息用于树节点Visitor遍历的CBO 优化： Hive统计元数据：调用HiveStatisticsProvider#getTableStatistics方法，底层调用对应Metastore Client RPC接口，包括 getTableStatistics
54142编辑于 2024-05-12 - 来自专栏Oracle数据库技术
深入SQL执行计划之CBO查询转换(4)：Group By 配置最优机能（Group By Placement）
那是不是说 CBO 只是盯着 View，或子查询来做工作呢，结论当然不是了。 ; commit; SQL> select sum(t1.c2), t2.c2 from t1,t2 where t1.c1 = t2.c1 group by t2.c2; 2 3 4 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| T2 | 1 | 26 | 3 (0)| 00:00:01 | | 4 PLACE_GROUP_BY((t1)) */ sum(t1.c2), t2.c2 from t1,t2 where t1.c1 = t2.c1 group by t2.c2; 2 3 4 至此，CBO 的 SQL 自动转换这总结分享也就告一段落。希望能对各位同学有所帮助。如果能提出您的宝贵意见，那就非常荣幸了。
43120编辑于 2022-08-19 - 来自专栏bisal的个人杂货铺
CBO如何选择相同cost的索引
ACOUG年会杨长老的演讲中，曾提到一个问题， 一条SQL语句，两种执行计划的cost值相同，CBO是如何选择执行计划？ SQL> begin 2 for i in 1 .. 10000 loop 3 insert into z values(i, i); 4 end loop; 对于以下SQL， select * from z where a=1 and b=1; 根据10053显示，可以看出，IDX_Z_01和IDX_Z_02这两个索引，cost相同，CBO会选择何种执行计划 值相同的索引的选择》 http://www.dbsnake.net/handle-equally-costed-indexes.html 文章总结来讲， 对于Oracle 10gR2及其以上的版本，CBO 先验证(2)的观点，从上面10053可以看出，两个索引的cost相同，叶子块数相同，此时CBO选择的是IDX_Z_01，因为他的名字，排在IDX_Z_02前面， Best:: AccessPath:
1.3K60发布于 2019-01-30 - 来自专栏河湾欢儿的专栏
4.页面优化
为什么要优化？ 优化的好处 1.提升网页响应速度 2.有利于搜索引擎搜索 3.对后期维护比较方便 怎么优化？ 1.减少请求 2.减少文件的大小 3.页面性能 4.可读性、维护性 1.图片合并 2.css文件合并 （多个css文件合并为一个、少量的行内样式、避免import的方式引入文件） 3.减少图片的大小 （选择合适的图片格式） 4.css值缩写 5.0px 中px省略 0% 0 0.5可以写成.5 6.选择器合并 7.link标签引入样式放到head标签中 8.js脚本建议放在底部，等页面加载完之后再处理 尽量用语义化的标签来编写，有利于seo 15.类型和id名，以内容语义来命名 16.避免hack 17.模块化（一系列相关的结构做成一个模块来处理） 18.必要的时候添加注释，可读性比较好 比如说代码优化 ，大家试着说一下怎么优化？
51220发布于 2018-09-06 - 来自专栏技术杂记
Mysql 优化存储4
优化脚本 一般此过程会非常漫长，可以写一个脚本来后台运行，或简单的控制一下IO [hunter@opti-slave ~]$ cat opti.bash #! opti.bash >> /path/to/optimize.log 2>&1 & 通过监控 optimize.log 来判断执行完成状态 也可以通过查看监控，IOPS很能反映问题 ---- 恢复备份 优化完成后 ，立刻恢复备份 start slave; 通过对比前后数据文件大小，可以明显看到优化效果 一般少也能缩减5%的空间，平均在10%左右，我自己经历最明显效果的是减少了32%的空间，对于一个大库来说，能节省不少磁盘空间 ，并且对查询性能也有一定优化效果 ---- 命令汇总 pt-table-checksum --nocheck-replication-filters --nocheck-binlog-format --
41620编辑于 2022-03-21 - 来自专栏Java 汇总
4.Mysql 优化
1.ORDER BY的优化 某些情况下，MySQL使用索引排序，尽量避免使用 filesort 即使ORDER BY与索引不完全匹配，也可以使用索引，只要索引的未使用部分和额外的 如果是这样，优化器可能不使用索引。如果SELECT*只选择索引列，则使用索引并避免排序。 * FROM t1 WHERE key_part1 = constantORDER BY key_part2; ---- 假设 key_part1不是索引或索引的一部分，在条件中作为常量条件存在，则优化器也会使用索引 为了获得文件排序操作的内存，从MySQL8.0.12开始，优化器会根据需要递增地分配内存缓冲区，直到达到sort_buffer_size系统变量指定的大小，而不是像MySQL8.0.12之前那样预先分配固定数量的
1K20发布于 2020-10-29 - 来自专栏mathor
枚举+优化（4）——哈希表优化实例2
例3.四平方和 思路1：枚举abcd，判断a^2^+b^2^+c^2^+d^2^是否等于N 分析规模 a：0 ~ sqrt(500000 / 4) b：0 ~ sqrt(500000 / 3 font color = red>经验：1秒=10^8^ 思路2：枚举abc，判断N-a^2^-b^2^-c^2^是不是完全平方数 分析规模 a：0 ~ sqrt(500000 / 4) * d) == f.end()) f[c * c + d * d] = c; //枚举a，b的值 for(int a = 0;a * a <= n / 4; << c << " " << d << endl; return 0; } } } return 0; } 例4. ; return 0; } 第一次作业 先说说的思路，当时看到这题有点懵，可能还是对哈希算法掌握的不够，怎么都想不到用哈希的方法去做，索性先写了个O(N^2^)的两重循环，想着这几天学的优化
82950发布于 2018-06-08 - 来自专栏bisal的个人杂货铺
Oracle CBO选错执行计划的一种场景
#LB: 131196 #DK: 1216564 LB/K: 1.00 DB/K: 11.00 CLUF: 14149049.00 Index: ORGDATEINDEX Col#: 4 # ORDER BY DECODE(ST.TYPE#, 1,2,2,1, 19,3,20,4, #LB: 125310 #DK: 1259074 LB/K: 1.00 DB/K: 10.00 CLUF: 13360966.00 Index: ORGDATEINDEX Col#: 4 正如dbsnake书中所说，若系统批量导入数据，建议业务使用前，立即采集相关表的统计信息，因为每日22:00，才会进行统计信息自动采集，之间的时间差，就有可能因为统计信息不准，让CBO选错执行计划。 虽然CBO对于执行计划cost计算，属于机密，但是10053可以间接，让我们了解CBO如何选择，某一个执行计划，再根据表、索引等统计信息，结合来看，有可能就发现一些线索。
61360发布于 2019-01-30 - 来自专栏Oracle数据库技术
CBO 查询转换(3)：结合谓词下推机能（Join Predicate Pushdown）
咱们来接下来探讨一下 View 和表结合，这时候 CBO 会如何转换用户的 SQL 呢。 通常的一个 View 和表去结合，View 里没什么特殊处理的话，就直接去使用表作 JOIN 即可。 这种情况下，CBO 就会想展开困难的话，那要是把 View 和表结合的谓词下推到 View 中是不是会产生什么神奇效果呢。 | 1 | 6 | 3 (0)| 00:00:01 | | 3 | VIEW | | 1 | 26 | 4 (25)| 00:00:01 | | 4 | HASH GROUP BY | | 1 | 6 | 4 (25)| 00:00:01 | | 5 继续通过 10053 EVENT Trace 再去探究一下，CBO 是怎样实现的。
37410编辑于 2022-08-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号