那就得查查冲突的来源是不是都是在 cached table 上面

应该是由于重启导致了事务异常失败 之后数据中残留了大量的事务相关的锁 在重启之后的清锁过程，造成的事务延迟上升

key_skipped_count 是 rocksdb 里面的 key 的概念 而 total_keys / process_keys 是我们的 mvcc key 的概念 两者虽然都叫 “key”，但实际上是不同的东西 rockdb 提供的是 key-value 的 api tidb 会用这套 kv 的 api 实现 mvcc 的 api mvcc 的 key 是这样的，比如说一开始，写入一条 a = 3 的记录 那么 mvcc 层的 api 对外展示是 a => 3 而 mvcc 层的内部实现是 a_v0 => 3 从 rocksdb 层提供的 api 观察是 a_v0 => …

试试 set @@global.tidb_enable_paging = 0 之后观察看看 或者，不要 set global 先在单个 session 内 set @@tidb_enable_paging = 0 然后执行查询语句几次，观察下 copr-cache 命中率的情况 然后 set @@tidb_enable_paging = 1 再执行几次，对比两种情况的结果 确认下是不是 coprocessor paging 对 copr cache 的行为影响 @TiDBer_yyy

Create a issue https://github.com/pingcap/tidb/issues/46755 And we’ll handle it later.

1min30s 整，应该是走到了慢速 ddl 的逻辑，也就意味着走 etcd 快速变更那块有问题。 原理是这样的：ddl 的算法要保证，在 tidb1 上面执行了这个操作，tidb 2 3 4 … 上面都能看到最新的 schema 信息。有两种方式，一种是慢速路径，要求每个 tidb 去 load 最新的 schema，在一个 lease 时间内，schema 变更不会有两次。一个 tidb 不知道其它 tidb 是否使用了正确的 schema，但是它可以等待。其它 tidb 会在 lease 时间内加载最新的 schema，如果加载不到就自己停止服务。ddl owner 节点只要等完 le…

注意观察 topn 没有下推的 plan 里面，除了 topn 没下推之外，还有一个 UnionScan 算子 这个算子一般是在事务里面做读/写的时候，才会使用到的算子。 所以你可以这样验证一下，是不是这样的场景就没有用到 topn 下推 begin insert some data update xxx where xxx order by limit 1 rollback 而不在 begin 里面，直接执行 update xxx where xxx order by limit 1 就下推了… 如果是这个问题，可以给我们提一个 issue，应该是事务里面 union sca…

内存放大的许多因素: chunk 编码会导致数据放大,不同类型放大倍数不一样,其实 decimal 是放大比例很高的 RPC 消息读取之后，是一整块的内存，包含了不少 chunk，然后释放机制是，只有里面所有 chunk 消费完之后，这整块内存才释放.(比如说有 100 个 chunk，哪怕其中 99 个消费掉了,还有一个 chunk 被引用着,则整块内存无法释放) tidb_distsql_scan_concurrency这个参数，并发是一块，实际上还带了 channel 的，数据并发读上来并不是立刻消费,而是往 channel 写，由消费者去读 channel 消费. 由于 chann…

这个地方是一处 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 去观察? 相关的配置设置上之后，观察目录有没有生成临时文件, 来确认是否使用了 引入 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 拦下来，如果能落盘就落盘，如果不能时要…