这份整理得很全！如果能再补一句 V8 相比 V6 有哪些变化，备考的同学会更受用~
备考主要看原理和实操，V6 的笔记基本够用，V8 新增的部分对照官方文档补一下就行。
感谢分享，收藏了~
2 天前
新标准的核心还是想让社区里真实付出的伙伴被看见~ 活动主题和评选标准，大家有想法、有意见的直接可以随时在这条下面留言就行，我们会收集大家的意见再定稿。
想报名、想牵头办活动的同学也可以直接找我，我来对接~
2 天前
补几个容易被忽略的点：
挡 GC 的是"最早那个活跃事务的 start_ts"，不是事务跑了多久——所以 begin 之后只 select 不提交，一样会把 safepoint 卡住。
定位：SELECT * FROM information_schema.tidb_trx WHERE state=‘Running’ ORDER BY start_time; 重点看 START_TIME 和 MEM_BUFFER_BYTES。
兜底配置：TiDB 的 max-txn-ttl 默认 60 分钟，超了锁可能被清、事务提交不了；tidb_gc_max_wait_time 控制活跃事务能挡 GC …
2 天前
资源充足的情况下，收益排序大概是：
TiKV storage.block-cache.capacity——默认是系统内存的 45%，收益最直接（混部的话要手动压一下）。
TiKV grpc-concurrency、readpool 按核数配，别一次开太大。
TiDB 侧调查询内存配额和临时存储限额（tidb_mem_quota_query / tidb_server_memory_limit）。
PD 的并发调度参数只在扩容/迁移时临时放大，平时不用动。
但说实话，不是混部单实例的话，调参收益都比较有限，先把慢 SQL 和热点解决掉比调参有效得多。调的时候记得分批调、看监控~
2 天前
排查思路很清晰了，就是 TiKV 之间的 gRPC 连接池没就绪。reload 之后能恢复，说明是连接卡死在池子里，不是算法本身坏了。
两个方向：
看 tikv_raft_client_grpc_conn_pool_conn_num（TiKV-Details 的 Raft IO 面板），故障时段有没有贴着上限；贴着就是连接池不够。
调 grpc-concurrency 和 raft-client 的连接数。注意版本差异：8.5.4 起默认值是 grpc-raft-conn-num * 3 + 2，8.5.3 及之前默认只有 5——你是 8.5.1，默认很小，可以手动调到 8~16 试试。
…
2 天前
你这个情况我倾向是 TiFlash 侧的问题，不是磁盘数据坏了：%2D1.idx 就是 -1.idx，是一个空的 MinMax 索引段，正常读取路径不该在这里断言失败。而且你是新部署、每次不同表、重建副本没用、重启就好——重启能恢复说明是内存里的 DeltaTree 索引状态坏了，跟磁盘上的 Delta/Stable 数据没关系。
具体是不是已知 bug 得研发确认，我帮你反馈给研发看下。麻烦先给这几样，能加快定位：
TiFlash 完整报错日志（含 dmfile_path）
select * from information_schema.tiflash_replica
出问题的表结构…
2 天前
索引没问题的话，衰减大概率出在统计信息 + 分区裁剪上，按这个顺序查：
迁完跑没跑 ANALYZE？统计信息没有或者过期，范围查询的行数估算全偏，执行计划直接走歪。先 ANALYZE TABLE。
8.5 分区默认是 dynamic 裁剪，等值查询如果不带分区键，就是扫全分区。要么查询带上分区键，要么建全局索引。
迁移过来的 range 分区 region 没预打散，可以预切分一下再比扫描量。
每台 TiKV 12G 内存对 500G 的表偏紧了，先确认 TiKV 没在换页。
纯分析类的查询可以丢 TiFlash 跑。
另外 Oracle 的分区裁剪和 TiDB 的 Region 分布不…
2 天前
先说结论：游标（useCursorFetch）只救客户端，救不了服务端。只要 SQL 里有 Sort / HashAgg 这类阻塞算子，TiDB 得把结果全算完才吐第一行，游标等于白设。
排查三步：
explain 看有没有 Sort / HashAgg，有的话先想办法去掉；确认分区键进了 where，不然扫的是全部分区。
调大单 SQL 内存阈值：SET tidb_mem_quota_query = 32 << 30; 同时确认落盘是开着的——oom-use-tmp-storage（TiDB 配置）+ tidb_enable_tmp_storage_on_oom，Sort/HashJo…
2 天前
楼上说得差不多了，我补一下先后顺序：
先啃 Failed Queries——executor 报错每秒上百这个才是真正打爆的源头，去 TiDB 日志里按错误码 grep，大概率慢 SQL 就藏在这批报错里。
再治 TiKV 负载不均：16.62 基本闲着、其他几台都打满，用 pd-ctl hot read/write 找热点 region 拆掉；表没加 AUTO_RANDOM 或 SHARD_ROW_ID_BITS 的加上。
cop 高说明不少计算压在 TiKV 上，单实例的话 coprocessor 并发可以适当调大一点，但根子还是把慢 SQL 优化掉。
QPS 1.2K 不算高，先把…
2 天前
这个 panic 是本地 raft log 出问题了——leader 处理 append response 时按 index 去查本地的 term，没查到（entry 已经被截断/损坏），unwrap 直接把 TiKV 打挂。
处理顺序建议按这个来，先保数据再恢复：
先别让 k8s 一直无脑重启，把 panic 日志和 TiKV 的 data 目录留档；
如果集群多数副本还在、还能读写：走无损路线——坏掉的 store 先用 pd-ctl store delete 下线，再扩一台新 TiKV 进来，等 region 补齐了再换盘，别直接删 data 目录重建；
如果多数副本已经不可用、集…
2 天前
![[image]](https://pingkai.cn/tidbcommunity/forum/uploads/default/original/4X/f/1/4/f142ee6c04436c57efe1e1293986079648a93c04.jpeg){kind=link}
[Critical Bug] 当 TiKV 上 leader 数量超过 32768 时，日志备份和 RocksDB compaction 会出现阻塞
问题描述
如果单台 TiKV 拥有超过 32768 个 leader 时，日志备份可能出现阻塞、无法初始化。
同时，当触发此缺陷时，RocksDB compaction 也会被阻塞（详见 Github issue 中的更多细节），并最终由于触发流控导致无法写入。
问题根因
log_backup: “register backup stream ranges” is stuck forever when there are >32768 …
21 天前
没有更多内容了