SELECT COUNT(1) FROM cmstop_content con INNER JOIN cmstop_category cat ON cat.catid = con.catid AND cat.first_parentid = '201' AND FIND_IN_SET('204', cat.parentids) INNER JOIN ( SELECT content_tag.contentid FROM cmstop_tag tag INNER JOIN cmstop_content_tag content_tag ON tag.tagid = content_tag.tagid WHERE tag.tag = 'zyp-pid_Seven1855' ) content_tag ON con.contentid = content_tag.contentid WHERE con.STATUS = 6 AND con.modelid IN (1,3,10); PolarDB的sql为什么主节点和列存节点执行计划是一样的?只读行存节点执行计划不一样呢?
PolarDB的SQL执行计划在主节点和列存节点上相同的原因是因为这两个节点都使用相同的查询优化器和执行引擎。无论是主节点还是列存节点,它们都会根据查询的语法、表结构和索引等信息生成相同的执行计划。
然而,只读行存节点的执行计划可能与主节点和列存节点不同,这是因为只读行存节点上的查询优化器和执行引擎可能有所不同。只读行存节点主要用于读取大量数据的场景,因此它的查询优化器和执行引擎可能会针对读取性能进行优化,例如使用更高效的读取算法或调整查询执行的顺序等。
总之,PolarDB的主节点和列存节点执行计划相同是因为它们使用相同的查询优化器和执行引擎,而只读行存节点的执行计划可能不同是因为它在读取性能方面进行了特定的优化。
SQL查询的执行计划取决于多种因素,包括数据库的配置、数据分布、索引结构、查询优化器的决策等。对于PolarDB这样的分布式数据库,执行计划也可能受到存储引擎类型、节点类型(主节点、列存节点、行存节点等)以及数据分布的影响。
关于你提到的SQL查询,为什么主节点和列存节点的执行计划相同,而只读行存节点的执行计划不同,这可能与以下原因有关:
对,统计信息的同步这块会有延迟的差异,每个节点自己都是异步刷新统计信息,另外定位到之前我们做过一个选择率估算的优化,但在这个case里起到了负面作用,建议可以关掉这个优化:set optimize_ref_access_cost = off; 就可以选到正确的计划了。此回答整理自钉群“PolarDB 专家面对面 - 慢SQL索引选择优化器新特性”。
PolarDB的主节点和列存节点执行计划一样的原因可能是因为这个查询中没有涉及到列存索引的优化。在PolarDB中,主节点负责解析SQL语句、生成执行计划,并将执行计划下发给各个存储节点执行。如果查询中没有涉及到列存索引的优化,那么主节点和列存节点的执行计划就会是一样的。
只读行存节点执行计划不一样的原因可能是因为该查询涉及到了只读行存节点上的一些特定优化策略。只读行存节点主要用于存储历史数据,对于这种查询可能会采用不同的优化策略来提高查询性能。例如,只读行存节点可能会对表进行分区裁剪,只读取需要的数据,从而提高查询效率。因此,只读行存节点的执行计划可能与主节点和列存节点不同。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
PolarDB 分布式版 (PolarDB for Xscale,简称“PolarDB-X”) 是阿里云自主设计研发的高性能云原生分布式数据库产品,为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务。