一、TiKV 底层资源瓶颈：读延迟突增、进程 OOM 崩溃排障
TiKV 是集群存储基石，线程池分配、RocksDB 内存规划是稳定运行的第一道防线，也是线上故障最高发模块。
1. 统一读线程池耗尽，全集群 SQL 读超时
故障复现：业务上线一条无索引全表扫描 SQL，单次扫描千万行数据，批量拉取结果集。监控定位：Grafana 看板 TiKV-Details→Thread CPU 面板，Unified read pool线程占用瞬间拉满，请求队列持续堆积，业务批量抛出read timeout报错。底层原理：UnifiedReadPool 承载所有普通快照读、SELECT 查询流量，线程资源耗尽后新请求无法分配执行线程，直接排队超时。落地优化方案
- 业务侧为查询条件建立联合索引，大幅缩减扫描行数；
- 超大查询拆分成分页查询，单次返回行数控制在万级以内；
- 配置监控告警，读池 CPU 使用率超过 80% 触发预警，提前拦截低效慢 SQL。
2. RocksDB Block Cache 配置超标引发 TiKV OOM
故障场景：人为调大rocksdb.block-cache-size参数，数值超过服务器物理内存 45% 安全阈值，同时执行大批量 Truncate 清空超大业务表。根因拆解：Block Cache 负责缓存磁盘数据块，占用大量常驻内存；批量 Truncate 会生成海量 MVCC 删除版本，双重内存压力直接击穿系统上限，操作系统强制 Kill TiKV 进程。标准化配置规范
- block-cache-size 固定设置为物理内存 30%~40%，生产环境严禁突破 45% 红线；
- 大表清空禁止一次性 Truncate，改用分批 Delete 逐段删除数据；
- 新增 TiKV 内存占用监控面板，内存突增时快速溯源大事务、全表扫描 SQL。
二、Region 热点负载调优：写入 / 读取单点压力均衡
分布式数据库天然存在 Region 倾斜风险，分为写入热点、读热点两类，分别对应主键设计、自动分裂两套长效解决手段。
1. 自增主键 INSERT 写入单点热点
问题现象：表采用 INT 自增主键，所有新增写入全部落在同一个起始 Region，单台 TiKV 节点 CPU 长期满载，其余节点负载闲置，集群算力利用率失衡。优化改造：建表时主键替换为AUTO_RANDOM随机主键，写入时主键值打散分配。验证效果：新写入数据均匀分发至全集群所有 Region 与 TiKV 节点，各 Store 磁盘写入、CPU 负载趋于平均，彻底消除写入瓶颈。
2. 高频小表单 Region 读热点
场景描述：配置类、字典类小表仅生成单个 Region，业务每秒上万次查询压垮单节点 QPS 上限。优化手段：开启Load Base Split负载自动分裂参数，TiDB 实时监控 Region 访问 QPS，自动将高流量单 Region 拆分为多个子 Region，流量分摊到多台 Store 节点，单点压力下降 60% 以上。
三、MVCC 误删数据应急恢复：DROP 与 TRUNCATE 差异化修复
TiDB 依靠 MVCC 多版本机制留存历史数据快照，提供两种恢复语法，但受 GC 生命周期硬性约束，是运维必须严守的操作红线。
- DROP TABLE 误删除恢复语句：
sql
FLASHBACK TABLE 业务表名 TO BEFORE DROP;
秒级还原整张表结构与全量历史数据，无额外依赖。
- TRUNCATE TABLE 清空误操作Flashback 无法还原 Truncate 清空数据，采用
RECOVER TABLE读取 GC 窗口内 MVCC 历史版本完成全量还原。 - 核心管控参数
tidb_gc_life_time控制历史快照保留时长，默认 10 分钟；交易、财务等核心业务可临时调高至 1~3 小时，拉长应急恢复窗口期；故障处理完毕后调回默认值，避免多版本堆积膨胀磁盘空间。
四、PD 调度深度优化：均衡全集群 Leader 分布
PD 作为全局调度中心，Leader 副本扎堆会造成节点算力浪费、故障切换风险升高，借助 pd-ctl 工具可快速诊断并自动均衡。
- 诊断命令：
pd-ctl store，查看每台 Store 绑定的 Leader 副本数量，直观识别 Leader 扎堆节点； - 两大核心诱因：集群存在大量细碎空 Region 无法合并、历史热点 Region 长期绑定单节点；
- 均衡落地步骤
- 开启
Region Merge自动合并微小空 Region，消除调度碎片； - 按需调整各 Store 的
leader-weight权重，给低负载空闲节点调高权重值； - PD 后台调度器自动迁移 Leader 副本，10~30 分钟内全集群 Leader 数量趋于均衡。
五、多机房高可用架构实测：同城多 IDC 容灾 RPO 验证
搭建三套主流同城部署架构，模拟整机房断电故障，实测数据丢失指标与业务切换能力：
- 同城三中心（三副本分属 3 个 IDC）依托 Raft 过半副本存活机制，单机房整体断电后，剩余 2 个 IDC 副本满足过半条件，RPO=0 无数据丢失；PD 自动重新选举集群 Leader，业务无感知无缝切换，为核心交易业务首选架构。
- 同城双中心同步复制主机房、备机房副本实时同步，主机房宕机时备机房数据完全一致，RPO=0，业务可直接切换至备集群承接流量。
- 同城双中心异步复制数据异步同步存在时间差，主机房突发故障时备库存在数据延迟，RPO＞0；故障后需手动解析补齐滞后 binlog 数据，仅适用于非核心、可容忍少量数据丢失的业务。
六、生产运维落地总结
- 监控前置是降本关键：TiKV 线程池使用率、RocksDB 内存水位、Region 分布、Leader 副本计数四大指标纳入日常巡检，提前告警远低于故障抢修成本；
- 热点预防优于事后调优：新表上线强制规范主键采用 AUTO_RANDOM，高频小表提前开启负载分裂，从架构源头规避单点压力；
- 数据恢复存在时间硬限制：GC 生命周期决定 MVCC 可恢复窗口，核心业务务必提前加长快照保留时长；
- 高可用架构优先级排序：三 IDC 三副本＞双中心同步复制＞双中心异步复制，金融、交易核心业务禁止异步双中心部署；
- 整套排障、调优流程适配 6.5~7.1 全系列稳定版本，无实验室花哨操作，流程标准化可直接嵌入企业运维 SOP。