PolarDB的sql为什么主节点和列存节点执行计划是一样的?只读行存节点执行计划不一样呢？-[阿里云_云淘科技]

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语句、生成执行计划，并将执行计划下发给各个存储节点执行。如果查询中没有涉及到列存索引的优化，那么主节点和列存节点的执行计划就会是一样的。

只读行存节点执行计划不一样的原因可能是因为该查询涉及到了只读行存节点上的一些特定优化策略。只读行存节点主要用于存储历史数据，对于这种查询可能会采用不同的优化策略来提高查询性能。例如，只读行存节点可能会对表进行分区裁剪，只读取需要的数据，从而提高查询效率。因此，只读行存节点的执行计划可能与主节点和列存节点不同。