好消息，通过本次免费的活动，我也通过PTCP认证考试，获得了PTCP认证证书，距离上次PTCA获取认证已经快4年了吧，回想起来第一次由oracle转国产分布式数据库的基础知识还是tidb给的，现在虽然没从事tidb相关工作，但是想学习更多国产分布式数据库技术，本次很好的准备，这个是我收罗的PTCP认证的知识点学习，也正是按照这个大纲来学习应考，并且系统学习了下TIDB相关技术知识，分享给大家，希望对大家有帮助。
一、TiDB 集群管理（40%）—— 重中之重
表格
| 考点 | 核心内容 | 易错点 |
|---|---|---|
| TiUP 部署与运维 | tiup cluster deploy / start / stop / scale-out / scale-in / upgrade / patch 命令及参数；拓扑文件 YAML 格式（global、server_configs、tidb_servers 等字段） |
scale-in 对 TiKV 是下线下线，对 TiDB 只是移除；升级前必须检查 tiup cluster check |
| 滚动升级 | 升级顺序：PD → TiKV → TiDB → TiFlash；升级过程中 Region Leader 迁移机制；upgrade --offline 与在线升级区别 |
在线升级期间 QPS 会抖动，因为 Leader 需要迁移 |
| 扩容缩容 | TiKV 扩容后 Region 自动 rebalance；缩容 TiKV 前需先 tiup cluster scale-in 并等待数据迁移完成（store 状态变为 Tombstone） |
缩容 TiKV 时不能直接杀进程，必须通过 TiUP 操作 |
| 参数调优 | tidb_mem_quota_query（单条 SQL 内存限制）、tidb_server_memory_limit（TiDB 实例内存上限）、TiKV rocksdb / raftdb 参数、coprocessor.region-split-size |
参数作用层级：全局 vs 会话级别；修改后是否需重启 |
| Runaway Query | v6.x 引入的自动识别与资源管控机制；识别条件（执行时间、内存、扫描行数）；处置动作（Kill、Move to Background、Switch to Background） | 与手动 KILL 的区别；与 Resource Control 的关系 |
| 监控告警 | Grafana 关键 Dashboard：Overview、TiDB-Summary、TiKV-Details、PD；核心指标：QPS、Duration、Coprocessor Cache Hit、Region Health、Store Limit、Leader Balance |
热点问题看 TiKV-Details → Hot Read/Write；慢查询看 TiDB-Summary → Duration |
| 权限与安全 | TiDB 用户权限体系与 MySQL 兼容；CREATE USER、GRANT、ROLE；TLS 加密传输配置；审计日志 |
TiDB 暂不支持部分 MySQL 权限（如 column-level） |
| 会话管理 | SHOW PROCESSLIST、KILL、tidb_snapshot（历史数据读取）、tidb_enable_chunk_rpc |
KILL 在 TiDB 中可能杀的是连接 ID，与 MySQL 行为一致 |
二、备份与恢复（20%）
表格
| 考点 | 核心内容 | 易错点 |
|---|---|---|
| BR 原理 | 基于 MVCC + SST 文件直接备份 TiKV 数据；支持全量 + 增量；备份到 S3/NFS/本地 | BR 直接读 TiKV，不经过 TiDB SQL 层；对集群有性能影响，建议在业务低峰执行 |
| BR 命令 | br backup full / db / table、br restore；关键参数：--ratelimit、--compression、--checksum |
--ratelimit 限制速度，防止影响业务 |
| 快照备份 | 基于 tidb_snapshot 或 Dumpling 逻辑备份；适用小数据量、跨版本迁移 |
快照备份是逻辑导出，BR 是物理备份 |
| 恢复场景 | 全集群恢复、单库恢复、单表恢复、Point-in-Time Recovery (PITR) | PITR 需要日志备份（v6.1+），结合 BR 全量 + TiCDC / log backup |
| 备份策略 | 全量周期 + 增量/日志备份；存储选择（S3 推荐）；备份校验 | 备份后务必做 checksum 校验 |
三、数据迁移与同步（20%）—— 工具选型是核心陷阱
表格
| 工具 | 适用场景 | 不适用场景 | 常见故障 |
|---|---|---|---|
| TiDB Lightning | 全量数据导入（MySQL → TiDB），大数据量（TB 级），支持逻辑/物理导入模式 | 增量同步、实时同步 | checksum 失败（数据不一致）、磁盘空间不足、Region 分裂过多 |
| DM (Data Migration) | MySQL → TiDB 的持续增量同步；支持分库分表合并（Sharding） | 非 MySQL 数据源、TiDB → MySQL | 主从切换后 binlog position 丢失、DDL 兼容问题、自增主键冲突（分库分表场景） |
| TiCDC | TiDB → 下游（MySQL/Kafka/Storage）的实时变更同步；支持 PITR、异地灾备 | 全量初始化（需配合 Dumpling/Lightning） | Changefeed 卡住（GC safepoint 超过）、下游写入延迟、DDL 同步异常 |
| sync-diff-inspector | 上下游数据一致性校验 | 不能用于同步，只能校验 | 大数据量校验慢；分库分表场景配置复杂 |
高频陷阱题：
-
“MySQL 分库分表合并到 TiDB” → 选 DM
-
“TiDB 实时同步到 Kafka 做数据分析” → 选 TiCDC
-
“TB 级历史数据一次性导入 TiDB” → 选 Lightning（物理模式）
-
“验证迁移后数据是否一致” → 选 sync-diff-inspector
四、高可用与故障处理（20%）
表格
| 考点 | 核心内容 |
|---|---|
| Raft 协议 | Leader 选举、日志复制、多数派（majority）原则；TiKV 中一个 Region 默认 3 副本（1 Leader + 2 Follower） |
| PD 调度 | Region 调度（balance-region、balance-leader）、热点调度、副本补全、Store Limit 控制；pd-ctl 常用命令 |
| 组件故障 | TiDB 是无状态节点，故障不影响数据；TiKV 单节点故障靠 Raft 多数派保证可用；PD 奇数节点部署（3/5），Leader 选举 |
| 网络分区 | 少数派分区 → 无法写入但可读取旧数据；多数派分区 → 正常服务；脑裂防护靠 Raft |
| OOM 排查 | 看 Grafana TiDB-Summary → Memory Usage；常见原因：大查询、大事务、统计信息加载、连接数过多 |
| 热点问题 | 写热点：自增主键、时间戳前缀索引；读热点：小表全表扫描；解决：SHARD_ROW_ID_BITS、AUTO_RANDOM、分区表、Scatter Region |
| DDL 机制 | TiDB 在线 DDL（async / sync / none 模式）；ADMIN SHOW DDL JOBS；DDL Owner 在 TiDB 节点间选举；大表加索引可能慢 |
| 事务与 MVCC | Percolator 分布式事务模型；乐观锁 vs 悲观锁（默认）；tidb_txn_mode；MVCC 版本清理由 GC 负责（tikv_gc_life_time） |
| SQL 执行计划 | EXPLAIN / EXPLAIN ANALYZE；关注 cop[tikv] vs root 任务；索引选择、统计信息过期（ANALYZE TABLE） |