在PolarDB中请问ebie行数评估是怎么来的呢？-[阿里云_云淘科技]

在PolarDB中请问ebie行数评估是怎么来的呢？

以下为热心网友提供的参考意见

在PolarDB中，行数评估是通过对表的统计数据、基数估计以及算子代价模型来进行估算的。

统计信息：PolarDB的统计信息以逻辑表为单位，包括了逻辑表的行数、列的NDV（Number of Distinct Values）值、列的空值信息以及等高直方图信息。当用户执行ANALYZE TABLE命令或者后台的auto analyze线程自动发起统计信息收集时，PolarDB会通过采样数据来计算统计信息。
基数估计：基数估计会利用各表、列的统计信息，估算出各算子的输入行数、选择率等，提供给算子代价模型，从而估算出查询计划的代价。例如，在Join操作中，LeftRowCount乘以RightRowCount，然后除以两者中较大的基数，可以得到Join操作的输出行数。
代价模型：PolarDB使用代价模型来描述物理执行计划的代价，通常用（CPU、Memory、IO、Net）四元组来描述。每个算子都会有自己的代价模型，而这个模型的输出（即代价）是所有算子代价的总和。最终，优化器会根据这些代价信息，选择代价最小的执行计划来执行SQL操作。

综上所述，PolarDB中的行数评估是基于统计信息和基数估计，结合代价模型综合得出的，目的是为了优化器能够选择一个性价比最高的执行计划。

以下为热心网友提供的参考意见

在PolarDB中，ebie行数评估主要是通过读取测试进行的。当单表数据行数从5万上升到60亿时，由于btree深度问题，读取测试中PolarDB可能会有一定下降，但基本在预期之内。写入的场景下，随着并发增长，性能逐渐逼近。在并发小的场景下，大表写入可能会有一定的性能衰退，但整体上看单大表的性能是可以维持的。同时，PolarDB也支持并行查询框架，当打开并行查询开关并且查询数据量到达一定阈值时，就会自动启动并行查询框架，从而使查询耗时指数级下降。这种并行处理能力利用了多核CPU的优势，可以显著提高查询效率。

以下为热心网友提供的参考意见

具体情况还是要看具体分析，优化器设计上，驱动表和连接的表中匹配的数量是有对应的。如果行数比较少的话，一般通过dive拿匹配的数量，行数多的话走统计信息。您这个是因为前面加了 prefix，所以join顺序固定了，对于表 ebie 采用的是 ref扫描，对应的 ref条件是 erp_ql_63.a.billid 。对于索引idx_profileid_sorcebillid 来说，ref扫的时候并不知道sourcebillid 具体的值是几，因为 a.billid 不确定，所以ROWS 是索引idx_profileid_sorcebillid 的总行数
您可以看下 optimizer_trace 中有比较详细的优化路径。此回答整理来自钉群“PolarDB 专家面对面 – 慢SQL索引选择优化器新特性”