【YashanDB 知识库】由于 hist_head$ 中 analyze time 小于 tab$ 中 analyze time 导致的 sql 语句执行慢

本文内容来自 YashanDB 官网，具体内容请见https://www.yashandb.com/newsinfo/7459465.html?templateId=1718516

问题现象

某局点 yashandb cpu 使用率 100%，经线上分析是由于几个 sql 执行慢，其中一个 sql 为简单的单行等值绑定变量过滤+排序。

经分析执行计划，相对以前有所变化，走了另外一个索引(效率低)。

问题的风险及影响

sql 语句执行慢，客户的业务受到影响。操作系统 cpu 100%可能导致宕机。

问题影响的版本

22.2.10.100

问题发生原因

hist_head$中表对应列的analyzetime小于tab$中表的 analyze time，在执行到 estColEqualOrNotParam 方法时，由于第一个参数 colStats 为 null 导致获得默认 selectivity(0.04)后退出。而实际选择率为 0.00003，相差甚远，优化器最终估算出来的 cost 不准，选择了错误的执行计划。

解决方法及规避方式

客户现网通过将错误的索引 invisiable 后规避。

问题分析和处理过程

现网错误的执行计划及估算出来的 rows 及 cost(sql 语句中有 hint，可以忽略，实际不加 hint 也走的是这个执行计划):

过滤条件中 sub_account_id 的选择性很好，表的总数据量为 6 千万左右，count(distinct)值为 200 万左右。很明显，上图中执行计划估算出来的 rows 是明显失真的。

实际正确的执行计划及 cost 如下(where 语句中多了几个 predicate，不影响总量本质)：

实际优化器在加载列的统计信息用于估算时，如果 hist_head$中analyzetime小于tab$中 analyze time，或者 hist_head$中没有表中相关列的数据，那么就会用默认的 selectivity(0.04)来做过滤条件估算，最终导致执行计划走偏。

经验总结

hist_head$中存放了列的普通统计信息，histgrm$中存放了列的直方图信息