tiancaiamao
tiancaiamao
V6
2019-11-27 加入
获赞
55
回答
150
文章
1
    那就得查查冲突的来源是不是都是在 cached table 上面
    6 个月前
    应该是由于重启导致了事务异常失败 之后数据中残留了大量的事务相关的锁 在重启之后的清锁过程,造成的事务延迟上升
    6 个月前
    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 => …
    7 个月前
    试试 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
    8 个月前
    Create a issue https://github.com/pingcap/tidb/issues/46755 And we’ll handle it later.
    9 个月前
    1min30s 整,应该是走到了慢速 ddl 的逻辑,也就意味着走 etcd 快速变更那块有问题。 原理是这样的:ddl 的算法要保证,在 tidb1 上面执行了这个操作,tidb 2 3 4 … 上面都能看到最新的 schema 信息。有两种方式,一种是慢速路径,要求每个 tidb 去 load 最新的 schema,在一个 lease 时间内,schema 变更不会有两次。一个 tidb 不知道其它 tidb 是否使用了正确的 schema,但是它可以等待。其它 tidb 会在 lease 时间内加载最新的 schema,如果加载不到就自己停止服务。ddl owner 节点只要等完 le…
    9 个月前
    注意观察 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…
    9 个月前
    内存放大的许多因素: chunk 编码会导致数据放大,不同类型放大倍数不一样,其实 decimal 是放大比例很高的 RPC 消息读取之后,是一整块的内存,包含了不少 chunk,然后释放机制是,只有里面所有 chunk 消费完之后,这整块内存才释放.(比如说有 100 个 chunk,哪怕其中 99 个消费掉了,还有一个 chunk 被引用着,则整块内存无法释放) tidb_distsql_scan_concurrency这个参数,并发是一块,实际上还带了 channel 的,数据并发读上来并不是立刻消费,而是往 channel 写,由消费者去读 channel 消费. 由于 chann…
    1 年前
    这个地方是一处 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 的方式计算的。 另外,如果这个场景下是…
    1 年前
    这个原因是,这是一个非关联子查询,tidb 在 编译期提前把这个子查询执行 并得到结果了, 再拿得到的结果,去继续构造 plan,然后再执行… 你注意观察一下 plan 可以发现, 这个东西里面 8102913.765246800000 就是子查询提前计算出来的结果 sum(ps_supplycost * ps_availqty) > (select 子查询 ) 就被转成了 gt(Column#33, 8102913.765246800000) 这样的条件 所以你看到的生成执行计划时间过长,是因为在生成执行计划的过程中执行了子查询的 sql,并且耗时算在生成计划里面了。 这…
    1 年前
    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 的时候对这块有一些优化…
    1 年前
    有查询的 query 的表结构不? 最小可复现的例子会方便排查
    1 年前
    如何判断这个参数生效了,或者在SQL执行是确实使用了临时空间 要不把这个值调小,然后执行相应的 query 去观察? 相关的配置设置上之后,观察目录有没有生成临时文件, 来确认是否使用了 引入 oom-use-tmp-storage 的时间点,和各个算子对落盘的支持的时间点,可能还不太一样 所以文档也没有很细化说哪些算子,从哪个版本开始支持了 可以用尽量新的版本测试
    2 年前
    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_…
    2 年前
    [image] 本地试了一下无法复现. 你是不是用了 SPM 呀, SPM 的优先级似乎会高于 hint ,导致 hint 失效
    2 年前
    如果要升级,建议在没有 DDL 执行中的时候升级,否则不太安全比如容易出问题
    2 年前
    具体的版本… 假设 v6.2 以后吧 我们近期做了大量的工作,来避免 OOM 的问题(进行中),在接下来会发布出去的版本会感受到这些变化。 至于 oom-use-tmp-storage 这个选项,并不是带上它就不会 OOM 了 举个例子,内存快到 OOM 临界点了,然后去落盘,落盘的速度跟不上内存继续申请的速度,然后还是 OOM 了 就内部实现的完善程度看,对 tidb_mem_quota_query 的支持是更好的 oom-use-tmp-storage 只支持了一部分的算子。预期是 tidb_mem_quota_query 一定要将 OOM 拦下来,如果能落盘就落盘,如果不能时要…
    2 年前