在PolarDB中为什么单表没有命中任何行索引的情况下，还是选择走了行的执行计划？

在PolarDB中，即使单表没有命中任何行索引的情况下，仍然选择走了行的执行计划，可能与以下几个关键因素有关：

1. 优化器的代价评估机制

PolarDB的优化器会根据查询的预估执行代价来选择执行计划。如果列存索引的执行代价高于行存执行计划的代价，优化器会选择行存执行计划。这种决策基于以下几点： - 行存和列存的执行代价对比：优化器会计算行存串行执行、行存并行执行（Parallel Query）以及列存执行（IMCI）的代价，并选择代价最低的执行计划。 - 阈值限制：只有当SQL的预估执行代价超过一定阈值（如loose_cost_threshold_for_imci）时，优化器才会考虑将查询下推到列存节点。如果预估代价低于该阈值，优化器可能会直接选择行存执行计划。

因此，即使没有命中行索引，只要行存执行计划的代价更低，优化器仍会选择行存执行。

2. 列存索引的覆盖范围

列存索引只能访问被其覆盖的列。如果SQL语句中涉及的列未被列存索引完全覆盖，列存索引将无法生效，优化器会回退到行存执行计划。具体来说： - 可以通过存储过程dbms_imci.check_columnar_index()检查SQL语句中的表或列是否已创建列存索引。如果返回结果表明某些列未被覆盖，则列存索引无法使用。 - 如果列存索引未完全覆盖SQL所需的列，优化器会优先选择行存执行计划，因为行存可以访问所有列。

3. SQL特性支持的限制

并非所有SQL特性都支持列存索引。如果SQL语句中包含列存索引不支持的操作（如某些复杂的子查询或特定的聚合函数），优化器会回退到行存执行计划。例如： - 列存索引可能不支持某些复杂的关联子查询或带有DISTINCT的聚合函数。 - 在这种情况下，优化器会根据SQL的兼容性选择行存执行计划。

4. 行存有序索引的优势

在某些场景下，行存的有序索引（如主键索引或二级索引）可能比列存的执行效率更高。例如： - 如果查询条件能够利用行存的有序索引进行快速定位（如ORDER BY或GROUP BY操作），优化器可能会选择行存执行计划，因为行存索引的扫描效率更高。 - 特别是在小数据量或低复杂度查询的情况下，行存的有序索引可能比列存的全表扫描更高效。

5. 自动引流机制的影响

PolarDB支持“行存/列存自动引流”功能，但该功能依赖于SQL的预估执行代价和连接地址的配置。如果SQL未被转发到只读列存节点，优化器会默认选择行存执行计划。具体原因可能包括： - 数据库连接地址未包含只读列存节点。 - SQL的预估执行代价未达到自动引流的阈值（如loose_cost_threshold_for_imci）。 - 可以通过添加/*FORCE_IMCI_NODES*/ Hint强制将SQL转发到列存节点进行验证。

6. Plan Cache的影响

PolarDB提供了Auto Plan Cache功能，用于缓存SQL语句的执行计划。如果某条SQL语句的执行计划已被缓存，且缓存的计划是行存执行计划，优化器可能会直接复用该计划，而不会重新评估列存索引的可行性。这可能导致即使列存索引可用，优化器仍选择行存执行计划。

总结

综上所述，在PolarDB中，即使单表没有命中任何行索引，优化器仍可能选择行存执行计划的原因主要包括： 1. 行存执行计划的预估代价低于列存执行计划。 2. 列存索引未完全覆盖SQL所需的列。 3. SQL特性不支持列存索引。 4. 行存有序索引在特定场景下的效率更高。 5. 自动引流机制未将SQL转发到列存节点。 6. Plan Cache中缓存了行存执行计划。

建议用户通过以下步骤排查问题： - 使用EXPLAIN查看执行计划，确认是否选择了行存执行计划。 - 检查SQL的预估执行代价（Last_query_cost）是否低于列存索引的阈值。 - 调用dbms_imci.check_columnar_index()验证列存索引的覆盖情况。 - 确认数据库连接地址是否包含只读列存节点。 - 检查是否有不支持列存索引的SQL特性。

通过以上方法，可以更准确地定位问题并优化查询性能。