TIDB遵循索引最左原则，但是最左索引原则会被范围查询中断。所以不应该是sql where条件中顺序的问题？
调整成如下试试呢？
... ...
seller_user_id = 1565305001
AND fee_type IN (
'G0002',
'A0011',
'GF002',
'GD002',
'GR002',
'GN002'
)
AND gmt_created >= '2024-09-15 00:00:00.0'
AND gmt_created <= '2025-09-15 23:59:59.0'
... ...
1 个月前
我之前遇到的问题也是checksum花费较长的时间，而且会影响到集群的查询性能（query summary中的99分位的duration 和 command Per second）
后来调整了下这个 checksum-concurrency 参数，checksum时间缩短了好些， 99分位查询波动也很少，不影响 command Per second
[image]
可以作为参考
![[image]](https://asktug.com/uploads/default/original/4X/5/d/2/5d212356c8f0c172412b06d6bd69bf4d0a440520.png){kind=link}
1 个月前
这个逻辑是从哪里看到的， 是截图的项目源码吗？
那如果是这个逻辑的话，意思TiKV节点开始下线之后，想要加速就不能修改 store limit 了，不，应该是不能通过 store limit all xxx 来修改所有的，只能通过 store limit store-id xxx 修改除了offline状态的其他所有节点是吧？
2 个月前
那有两个疑问：
1、从这里看上限是“无限制” ，但是不能真的是无限制吧。 之前store-limit 设置的 add-peer / remove-peer 是45 ， 我理解实际是按照45限制的才对， 除非这里的store limit 配置的45一直没有生效？
2、如果没有生效的话，我不管修改成多少，相对于无效大肯定是变得“很小”了如果是生效的情况下，45调整到60 应该是调大是合理的才对，
2 个月前
哦哦，明白你的逻辑了，相当于通过一个大存储的NAS当备份中转， BR的备份和恢复都在“本地”进行了。也是一种方案呢，谢谢~
2 个月前
这样的话需要集群集体停止服务吧？虽然是内部环境，但是要求是不能中断，数据量也挺大的
2 个月前
已确认是防火墙拦截了三个TiKV节点导致的，添加路由和防火墙放心之后就恢复了。感谢大佬
2 个月前
你的回答给了我一个思路，因为br最终实际是copy tikv的sst文件到minio的，br 开始备份时一些基本信息都写入到了minio了，但是实际tikv的sst没有。 我可能猜到什么问题了
2 个月前
我的情况比较特殊，相当于是从一个环境搬迁到另外一个环境，两个隔离的环境之间使用vpn打通的
2 个月前
重新上传备份到办公网络错误的日志
br-neibu-tidb2office-with-errors-copy.log (183.1 KB)
2 个月前
没有更多内容了