【YashanDB知识库】由于hist_head$中analyze time小于tab$中analyze time导
本文内容来自YashanDB官网，具体内容请见https://www.yashandb.com/newsinfo/7459465.html?templateId=1718516题目现象
某局点yashandb cpu使用率100%，经线上分析是由于几个sql实行慢，其中一个sql为简单的单行等值绑定变量过滤+排序。
经分析实行筹划，相对从前有所变化，走了另外一个索引(效率低)。
题目的风险及影响
sql语句实行慢，客户的业务受到影响。操纵系统cpu 100%可能导致宕机。
题目影响的版本
22.2.10.100
题目发生缘故原由
hist_head$中表对应列的analyze time小于tab$中表的analyze time，在实行到estColEqualOrNotParam方法时，由于第一个参数colStats为null导致得到默认selectivity(0.04)后退出。而实际选择率为0.00003，相差甚远，优化器最终估算出来的cost禁绝，选择了错误的实行筹划。
办理方法及规避方式
客户现网通过将错误的索引invisiable后规避。
题目分析和处理过程
现网错误的实行筹划及估算出来的rows及cost(sql语句中有hint，可以忽略，实际不加hint也走的是这个实行筹划):
https://img2024.cnblogs.com/blog/3434249/202409/3434249-20240927112959196-938212062.png
过滤条件中sub_account_id的选择性很好，表的总数据量为6千万左右，count(distinct)值为200万左右。很明显，上图中实行筹划估算出来的rows是明显失真的。
实际正确的实行筹划及cost如下(where语句中多了几个predicate，不影响总量本质)：
https://img2024.cnblogs.com/blog/3434249/202409/3434249-20240927113021558-32341205.png
实际优化器在加载列的统计信息用于估算时，如果hist_head$中analyze time小于tab$中analyze time，大概hist_head$中没有表中相关列的数据，那么就会用默认的selectivity(0.04)来做过滤条件估算，最终导致实行筹划走偏。
经验总结
hist_head$中存放了列的普通统计信息，histgrm$中存放了列的直方图信息
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]