Loop 分析如下：
您好，关于日志 [INFO] [select.go:565] limit executor close takes a long time，结论如下：
这不是报错，也不代表查询慢。 它是 TiDB 内置的一条诊断日志：一条 SQL 执行结束、释放执行算子链时，如果这一步耗时超过 1 毫秒就会打印一条 INFO。1.5ms、几十毫秒这种量级属于正常抖动——正因为阈值定得很低，它容易刷屏，但对结果正确性和查询响应时间都没有影响。
特别说明一点：您帖子里那条 LIMIT 10000 的查询（执行计划是 IndexLookUp + Limit 下推）本身不会打印这条日志—…
6 天前
相关表的 tiflash 副本 set replica 为 0，释放后再加回来问题能解决么？9 天前
我还真没这么用过，这么用的也很少。
ai 找的这个配置 最好测试下吧。
1 个月前
问题归纳
社区 topic/1059924：v7.5/v8.5 配 max_execution_time=2s 超时断链后，TiKV 侧 cop 任务仍在跑（TiKV deadline 默认 60s）。用户问：能否用 tikv_client_read_timeout=3s 缩短 TiKV 侧 deadline、加快任务出清？
结论（三 agent 一致）
① 机制上「能缩短 deadline」，但「不能加快出清已 running 的任务」
deadline 真透传：TiDB coprocessor.go:1197-1199 算 timeout（tikv_client_read_timeo…
1 个月前
监控 tikv detail >> thread cpu 发来看看，里面有一些线程 cpu 使用情况，看看有没有瓶颈。
落 KV 用法社区支持挺弱的。。。。
1 个月前
AI 分析：
社区问题 1059034 结论：
根因：离线环境 tiup br 的本地 mirror 元数据过期后尝试联网刷新 → 超时 hang。不是强制要求最新版，是 tiup 的本地缓存机制在离线环境不可靠。
方案：直接用安装包自带 BR 二进制，绕过 tiup：
./br backup db --db test --pd "pd-host:2379" \
--storage "local:///backup/" --check-requirements=false
同版本 BR + 同版本集群无兼容问题，--check-requirements=false 安全可加。
社…
2 个月前
如果服务器的 cpu 内存、io 用的不高。
网络带宽也没有到瓶颈。
那么监控 ping 5ms 算高得了。因为默认 blackbox 的 ping 是一个很小的请求，并且会被 15s 弱化掉。
tidb 读取 跨网络的，网络影响还是比较大的。
3 个月前
社区问题 1057818（v8.5.4 慢 SQL IndexLookUp）根因结论
一、根因（一句话）
TiKV coprocessor 在 “tracker 之外” 的调度段（gRPC handler → unified-read-pool 排队 + parse_request + region cache 查询）累计 ~518ms，叠加 gRPC 往返 ~429ms；TiKV 自身计算/锁/snapshot/IO 都不是瓶颈。混部 3 台环境是放大器。
二、铁证三段 gap 拆解
IndexRangeScan_13 cop_task：
段
公式
耗时
性质
gap A…
3 个月前
社区 topic/1057715 分析报告 — Dashboard 日志搜索 CANCELLED
社区问题：dashboard日志搜索所有tikv节点的日志
版本：v8.5.3 | 客户：社区用户 | 现象：Dashboard 日志搜索搜不到 tikv(10.0.1.228:20160) 的日志，PD 报 LogSearchTask stopped with error... rpc error: code = Canceled desc = CANCELLED
1. 问题澄清
Dashboard log search 搜不到特定 TiKV 节点日志，PD 日志同时出现两类告警：
L…
3 个月前
社区 topic/1057681 综合分析报告
问题：tidb_mem_quota_binding_cache 生产配置参考、调大隐患、监控方案
版本：v7.5.3
一、参数机制（源码确认）
tidb_mem_quota_binding_cache 控制 binding 计划缓存的字节级内存配额，默认 64MB。底层是 kvcache.SimpleLRUCache，条目数无上限，纯按字节触发 LRU 淘汰。通过 memory.Tracker 挂到 TiDB 全局内存树，受 server 总 OOM 管控。
二、核心澄清：调大不会让 SQL 匹配变慢
这是社区最常见的误解。源码确认 bi…
3 个月前
AI 综合分析
最终结论 + 对客回复
核心结论
tikv#18109 已知 bug，TiKV v8.5.4 受影响，目前无 fix。
TiKV 启动 init 阶段调用 block_on(pd_client.get_tso()).expect(...) 获取首次 TSO，该调用无重试机制。底层 tso-worker 线程因 TSO gRPC stream 异常退出后，所有 pending 的 oneshot 通道被 drop，报 “Timestamp channel is dropped” → 直接 FATAL panic。
该问题已被客户独立上报为 tikv#19845（2026-07…
3 个月前
![[image]](https://pingkai.cn/tidbcommunity/forum/uploads/default/original/4X/9/0/a/90afe3d7151f6562d244490078a45aaac5d69e5f.jpeg){kind=link}
重启还是搞不定么？
我这边内部 AI 分析了下，历史上遇到的问题可能是 pd 这边有时钟跳转或者当时卡了下。
pd leader 的日志发一下。
3 个月前
辛苦提供下完整的 tikv panic 以及前后日志。
我让 AI 先分析下。
你 br 恢复，br 版本是 v8.5.4 的么？日志也上传一份呗。
3 个月前
没有更多内容了