分布式数据库tidb原理和架构怎么理解

你在项目里被安排评估一套分布式数据库，或者线上单机库已经扛不住写入，同事丢来一句「上 TiDB 吧」，你却发现资料都在讲名词，没人告诉你这些分层到底解决了什么问题。这篇按「先看它拆成了几块、再看向上暴露什么、最后看一致性怎么兜底」的顺序走一遍，每个环节都给出可以自己动手验证的动作，不背概念。

被安排评估分布式数据库，或者线上单机库已经扛不住写入，同事丢来一句「上 TiDB 吧」，结果资料翻一圈全是名词，没人告诉你这些分层到底解决了什么。这篇按「先看它拆成几块、再看向上暴露什么、最后看一致性怎么兜底」的顺序走一遍，每个环节都给能自己动手验证的动作，不背概念。

先记住一句话：TiDB 不是靠某个黑科技变快，而是把「不存数据的计算」和「存数据的存储」分开，再用一套事务协议把两边缝起来。理解了这条主线，下面所有分层名词都能对上位置。想先看同类方案的价格与配置对比，可以到 /price-watch 核对当时的数字。

先搞懂为什么要拆成两层

把无状态的计算层和有状态的存储层分开，好处是加计算节点不用搬数据、加存储节点不用改业务连接串；代价是多了一跳网络往返，写延迟天然比单机高。它不是免费午餐，扩的是弹性，付出的是延迟。

• 判断要不要这套结构：读多写少、单表体量不大的库，拆层带来的运维复杂度可能不划算，先看单机加内存和索引能不能解决；
• 对账动作：把业务 SQL 按点查、范围扫、聚合、事务写四类列出来，估算每类占比，再决定要不要往分布式走；
• 反例：如果你的查询几乎全是主键点查且总量可控，单机加只读从库往往更省事，拆层收益很低。

SQL 层和事务层各管什么

计算层负责解析 SQL、生成执行计划、把请求路由到正确的数据分片，本身不存数据，所以能水平扩容，也能挂掉重启；事务层管的是「跨分片写要么全成要么全败」。理解它的关键是搞清事务开始、提交、落盘这几个阶段分别发生在哪一层。

1. 确认问题在哪一层写入卡住时，先看是计算层排队还是存储层单点热点，两者表现很像但处理方向不同，别一上来就加节点。
2. 看热点分布把分片请求量拉出来看是否集中在少数节点，热点通常来自自增主键或单调递增的写入键。
3. 验证路由对同一条 SQL 分别按不同条件执行，观察执行计划是否走了预期分片，确认路由规则和你的直觉一致。

一致性靠什么兜底，哪几种情况会读到旧数据

多副本的意义是容错而不是提速：某一副本挂了，集群还能选出新的负责人继续服务，副本数怎么定要看你能接受多长的不可用窗口。想对比不同方案的容灾能力，可以到 /rankings 看站内整理的维度。

• 会读到旧数据的典型场景：读写分离走从库、跨机房容灾切换期间、快照读与当前读混用的时候；
• 自测方法：写一条记录后立刻按不同读方式去读，观察返回是否一致，把差异记下来再决定业务的读写路径；
• 不适用情况：如果业务允许短暂读到旧值，就不必为了强一致付出额外延迟，先跟产品确认容忍边界。

怎么快速判断一致性有没有兜住

别只看文档描述，自己构造一个并发写场景：两个事务同时改同一行，观察其中一个是否被正确回滚或重试。这个动作比读十页原理更快让你建立直觉。

评估阶段该动手做的几件事

评估阶段最容易犯的错是拿造出来的均匀数据压测，跑出来的结果很好看，一上真实业务就冒热点。用真实业务 SQL 回放，比造数据有意义得多。

1. 列出监控指标写入延迟、单节点磁盘水位、事务冲突次数，这三项出问题时最容易被忽略，先接进看板再谈迁移。
2. 用真实 SQL 压测拉一段真实业务 SQL 回放，观察热点是否出现，造出来的数据分布往往太均匀跑不出问题。
3. 确认维护人选问清楚谁负责盯集群、谁处理告警，没人维护的集群出问题时排查成本会远高于收益。

不适合硬上的情况也说清楚：强依赖复杂多表关联、或者团队没有专人维护集群，硬上以后排查成本会高于收益。这时候保留单机加只读从库是更务实的选择。