- 【TiDB 版本】:3.0.13
- 【问题描述】:第一次执行时间和后续执行相差较大
- 第1次执行
– 0.156s
- 第2次执行
– 0.064s
- 第3次执行
– 0.056s
- 第4次执行
– 0.056s
update bill_detail_temp set rev_stop_status = 1 where bill_trans_no=‘B20181031162132161342’;
在tidb-3.0.13版本中测试 rev_stop_status设置为0和1循环执行实验。
为什么第一次 时间比后面几次相差一倍多。是有什么机制吗?
来了老弟
2
你好,
这边明确下问题:
请问第 1、3 次,所执行sql 条件为 rev_stop_status = 0
?第 2、4次,所执行sql 条件为 rev_stop_status = 1
?
来了老弟
4
你好,
怀疑和执行计划有关,并与 0、1 的数据分布有关系。
烦请反馈下下面 sql 的结果,并标注一下。
explain update bill_detail_temp set rev_stop_status = 0 where bill_trans_no=‘B20181031162132161342’;
explain update bill_detail_temp set rev_stop_status = 1 where bill_trans_no=‘B20181031162132161342’;
来了老弟
6
请问下再多执行几遍是否还是这样的分布呢,上下波动应该是正常的。
试了几次,感觉30秒-50秒一循环是的。如:
10:00:00开始执行
第1次执行 – 0.156s
第2次执行 – 0.064s
第3次执行 – 0.056s
第4次执行 – 0.056s
大概过个30到50秒在继续执行,又会出现【第1次执行 – 0.156s】和第一次的时间差不多,然后后面继续执行又变少了。
你说的这个应该有这可能,请问block cache缓存时间是多长呢。
我这变测试的大概30到50秒,一循环。
yilong
(yi888long)
10
我没有找到具体的时间设置,tikv中内置的rocksdb, rocksdb使用的 LRU Cache ,和你的业务也有关系,会有他的计算规则。 https://github.com/facebook/rocksdb/wiki/Block-Cache