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

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

1. 统计信息：PolarDB的统计信息以逻辑表为单位，包括了逻辑表的行数、列的NDV（Number of Distinct Values）值、列的空值信息以及等高直方图信息。当用户执行ANALYZE TABLE命令或者后台的auto analyze线程自动发起统计信息收集时，PolarDB会通过采样数据来计算统计信息。

2. 基数估计：基数估计会利用各表、列的统计信息，估算出各算子的输入行数、选择率等，提供给算子代价模型，从而估算出查询计划的代价。例如，在Join操作中，LeftRowCount乘以RightRowCount，然后除以两者中较大的基数，可以得到Join操作的输出行数。

3. 代价模型：PolarDB使用代价模型来描述物理执行计划的代价，通常用（CPU、Memory、IO、Net）四元组来描述。每个算子都会有自己的代价模型，而这个模型的输出（即代价）是所有算子代价的总和。最终，优化器会根据这些代价信息，选择代价最小的执行计划来执行SQL操作。

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

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

eft join中，如果on里面有右表的条件，会把左表的数据全部返回，右表的数据符合筛选条件返回，不符合设为NULL。所以 ebie.sourcebillid>0 这种非关联条件在表 ebie 是有作用的，会把最后的结果设置为NULL，只是代价估算时，这个条件是不在表ebie 上的，所以ROWS是总行数。此回答整理来自钉群“PolarDB专家面对面 - PolarDB for AI”