一台机器 部署了tifkash 机械盘 数据量较大 oom 定期重启下 tidb

官方最佳实践也不推荐扩大版本升级吧

看标题忍不住笑了，不该笑。 tidb不能回退吧。 有备份吗

No tasks yet BR 在 backupmeta 里没找到任何需要恢复的 SST，大概率是备份时表不存在或者 local 存储的文件不完整。

一.SPLIT 的本质：它只是在 _tidb_rowid 的空间上预先画了几个切分点（split points），把 [0, 2^63) 这个区间物理切割成多个 Region。但关键问题在这里：如果写的是单调递增的自增主键（CLUSTERED 表），新写入的 RowID 一个比一个大——它们永远落在最末尾那个Region 的范围内。SPLIT 切分出的前面那些 Region 根本不会收到任何新写入。 二.PD 热调度做了什么 探测热点：通过 TiKV 心跳中的 StoreState（磁盘、读写速率）和 RegionState（Leader 位置、读写速率）检测 热 Region 识别：检…

可能TiDB 的统计信息未及时更新，优化器可能 低估了数据量级 或 高估了索引选择性，导致放弃索引

TiDB 的优化器成本模型中，对回表操作的 网络延迟惩罚（network latency penalty） 非常重。当 TiDB认为回表代价高时，会倾向选择全表扫描 + 并行处理。

TiDB 不喜欢的不是二级索引本身，而是 大批量回表操作。当你的 SQL 经过二级索引筛选后仍需读取大量行时，TiDB 认为直接并行扫全表 + Coprocessor下推过滤效率更高。这是分布式数据库面对大量随机读时的理性选择——用计算换IO

TiDB 底层 TiKV 采用 Multi-Raft 架构，将数据划分为多个 Region，每个 Region 对应一个独立的 Raft Group，实现数据分片与复制；Region 的分裂、合并、迁移及集群负载均衡由 PD（Placement Driver）统一调度。 写入侧，TiKV 基于事件驱动模型处理 Raft Ready，各 Region 的 Raft 日志通过 RocksDB WriteBatch 批量提交落盘，并结合日志复制流水线（Pipeline Replication）、网络消息批处理等机制显著提升写入吞吐。 读取侧提供多种一致性方案： Raft Log Read：通过…

TiDB 底层 TiKV 依托 Multi-Raft 架构，将数据划分为独立 Region 对应单独 Raft 组完成数据分片，Region 分裂、合并、迁移与集群负载均衡由 PD 调度实现；TiKV 采用事件驱动模型处理 Raft Ready，各 Region 独立使用 RocksDB WriteBatch 批量落盘，搭配日志复制流水线、网络消息批处理提升写入吞吐。读取侧分层提供多种一致性方案：Raft Log Read 为写读合一强一致方案极少使用；ReadIndex 通过一轮多数派心跳确认 Leader 身份规避日志写入开销；Lease Read 依靠心跳持续续期租约，租约时长受选举超时…

什么样的水平

是不是可以改下日志级别 少产生些日志

分布式数据库 TiDB：原理、优化与架构设计 这本书有电子书吗？

Failed值是衡量 TiFlash MPP 引擎稳定性和查询健康度的重要指标。 如果该数值持续升高，说明 MPP 查询在执行过程中遇到了较多的阻碍或错误，需要结合具体的错误日志进行排查

跟着大家学习，部署中的各种情况。

自定义 shell 启动脚本未透传 SIGTERM（无trap转发），会造成 tidb-server 收到双重终止信号； 激进就绪探针（10s 探测周期、3 次失败即杀容器）会持续高频下发 SIGTERM，大幅提升并发信号竞争概率； Burstable QoS 容器 CPU 调度抢占，goroutine 时序抖动，更容易复现锁非法释放 panicTiDB。 这也是该 Bug 在 K8s 部署场景远高于物理机 / 虚拟机 TiUP 部署的核心原因。

TiDB 官方明确：日志备份（Log Backup）不支持 Windows 局域网 SMB/NFS 共享文件系统作为存储后端，生产推荐对象存储 S3/GCS/Azure Blob，本地存储仅支持 Linux 本地 EXT4/XFS SSD 磁盘。 文件锁、原子写机制缺失 TiKV 多节点并发写备份元文件（global_checkpoint、.meta分片文件）时，SMB/NTFS 共享没有 Linux 原生文件锁，出现文件覆盖、元数据写入失败：TiKV 本地生成了新日志段，但无法成功更新存储上的 checkpoint 元文件，本地 TS 无法同步至全局，全局 Checkpoint 卡死。 缓…

维度 评估 能否解决大表同步不推进 大概率能解决，大事务拆分为核心改进 版本兼容性风险 中等风险，跨大版本需谨慎测试 推荐升级版本 建议直接上 v6.5.10+，不要用 v6.5.0 初始版 升级复杂度 中等，需要重建 changefeed、重新测试 业务影响 需评估事务原子性丢失的影响

可以试试，有问题再说