这个地方是一处 explain 结果显示上面的 bug,并不是真正的统计信息用的不准
在 IndexHashJoin 的 Probe 侧的这个 estRows 只有 2.16,这个是估算的执行一次的代价
实际上 IndexLookUp_153(Probe) 这个要执行 4460440.32 次!
所以 2.16 3.57 这些数字都应该显示成 ? x 4460440.32 才是真正的 estRows
这个 2.16 之类的 estRows 的估算,确实如
@h5n1 和
@人如其名 说的,是通过 1 / NDV 这样的 distinct 的方式计算的。
另外,如果这个场景下是…
这个原因是,这是一个非关联子查询,tidb 在 编译期提前把这个子查询执行 并得到结果了,
再拿得到的结果,去继续构造 plan,然后再执行…
你注意观察一下 plan 可以发现,
这个东西里面 8102913.765246800000 就是子查询提前计算出来的结果
sum(ps_supplycost * ps_availqty) > (select 子查询 )
就被转成了 gt(Column#33, 8102913.765246800000) 这样的条件
所以你看到的生成执行计划时间过长,是因为在生成执行计划的过程中执行了子查询的 sql,并且耗时算在生成计划里面了。
这…
有查询的 query 的表结构不? 最小可复现的例子会方便排查
log.expensive-threshold 这个参数在新版本不起作用了
https://github.com/pingcap/tidb/pull/10350/
这个 PR 的改动之前, log.expensive-threshold 是通过优化器阶段,判断结果行数可能超过 1000 就会打 [EXPENSIVE_QUERY] 的 log
改动之后,误把这个行为给干掉了。而对应的文档没有及时更新,所以现状是 log.expensive-threshold 配置没啥用了
<在线修改配置> 那里面,应该也是文档错误, log.expensive-threshold 并不对应到 tidb_…
[image]
本地试了一下无法复现.
你是不是用了
SPM 呀, SPM 的优先级似乎会高于 hint ,导致 hint 失效
如果要升级,建议在没有 DDL 执行中的时候升级,否则不太安全比如容易出问题
具体的版本… 假设 v6.2 以后吧
我们近期做了大量的工作,来避免 OOM 的问题(进行中),在接下来会发布出去的版本会感受到这些变化。
至于 oom-use-tmp-storage 这个选项,并不是带上它就不会 OOM 了
举个例子,内存快到 OOM 临界点了,然后去落盘,落盘的速度跟不上内存继续申请的速度,然后还是 OOM 了
就内部实现的完善程度看,对 tidb_mem_quota_query 的支持是更好的
oom-use-tmp-storage 只支持了一部分的算子。预期是 tidb_mem_quota_query 一定要将 OOM 拦下来,如果能落盘就落盘,如果不能时要…
$ find . -name '*.go'|xargs grep EnableTmpStorageOnOOM
./config/config.go: // TempStorageQuota describe the temporary storage Quota during query exector when TiDBEnableTmpStorageOnOOM is enabled
./executor/sort.go: if variable.EnableTmpStorageOnOOM.Load() {
./executor/aggregate.go: if e.ctx.GetSessi…
是呀,这一阵在集中处理 OOM 相关的问题,其中就包括统计信息这块的改动
加 limit 去拿是对的… 但是当前有一个 bug,导致即使 limit 的情况下,其实还是拿全部数据的(性能不好并且容易造成OOM)。
我抽个时间修一修,就近期搞
这个设计是不太合理。
这个问题出现的原因是,我们默认 GC 的时候设置得不是太长(20min),否则有可能数据版本太多,影响性能。
但是有时候又有一些需要执行很长时间的后台任务,比如这里的 analyze,当集群规模稍大以后可能就要超 20min 了。以前的 analyze 工作在一个版本的 snapshot 上面,而 GC 把那个超过了 20min 的 snapshot 删除了,就出错了。
这个问题预期会在 6.2 版本中修复掉。
6.2 中 analyze 会将使用 max int64 的 tso,而不是一个快照的 tso。这样 analyze 分析的准确性会降低,不过对于 ana…
为什么子查询用了函数会导致结果集不稳定
这个问题不对。不是子查询用了函数导致的结果集不稳定,而是这个查询的结果本身是不保证稳定的。
这条 SQL 只一能给的保证是,结果是按 order by C 有序的,每次的结果集内容是一致的。
其它都是未定义行为,依赖于实现细节。
子查询里面不用 max 函数的时候,走的是一个 Apply 算子,更低效的实现,它恰好给你了一个有序的结果。而用 max 的时候,Apply 算子被优化成 HashJoin 了,是更高效的并发实现,高效并发的副产品是返回结果也不稳定了
对于单表查询的话,如果排序字段有值重复了,最终的输出结果是按什么规则确定顺序的
…
OK … 那就是有没有 sql_str 字段的区别…
这个字段的数据比较长,hash join 的时候 build 侧的 table 是需要全部加载进 tidb 内存的
占用了比较多的内存
还有一点因素是,数据到了 TiDB 的内存,会有一定的放大,最终就 OOM 了