这个地方是一处 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，并且耗时算在生成计划里面了。 这…

https://docs.pingcap.com/tidb/dev/explain-subqueries#null-aware-anti-semi-join-not-in-and--all-subqueries 是否带 null 会对 (anti) semi join 产生很大的影响，因为 join 的 eq 条件正常是 true or false 但是 null 的存在，eq 判断会存在 true or false or null 三种状态，null 的时候会需要特殊的处理 导致最后的查询计划是走笛卡尔积+filter 的形式，性能就会比较差 tidb 6.3 的时候对这块有一些优化…

有查询的 query 的表结构不？ 最小可复现的例子会方便排查

如何判断这个参数生效了，或者在SQL执行是确实使用了临时空间 要不把这个值调小，然后执行相应的 query 去观察? 相关的配置设置上之后，观察目录有没有生成临时文件, 来确认是否使用了 https://github.com/pingcap/tidb/blob/c7806eac6ff25e5a5117316fd5478fbe39b19bf6/config/config.toml.example#L31-L42 引入 oom-use-tmp-storage 的时间点，和各个算子对落盘的支持的时间点，可能还不太一样 所以文档也没有很细化说哪些算子，从哪个版本开始支持了 可以用尽量新…

https://github.com/pingcap/tidb/pull/37667 提了个 PR 去修一修

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 失效

A集群上面数据正常的不?

如果要升级，建议在没有 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 相关的问题，其中就包括统计信息这块的改动

https://github.com/pingcap/tidb/pull/36859 搞起!

加 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 了，是更高效的并发实现，高效并发的副产品是返回结果也不稳定了 对于单表查询的话，如果排序字段有值重复了，最终的输出结果是按什么规则确定顺序的 …

https://github.com/pingcap/tidb/pull/32756 我提了个小 PR 修一修这个问题

OK … 那就是有没有 sql_str 字段的区别… 这个字段的数据比较长，hash join 的时候 build 侧的 table 是需要全部加载进 tidb 内存的 占用了比较多的内存 还有一点因素是，数据到了 TiDB 的内存，会有一定的放大，最终就 OOM 了