缘起：为什么开始关注国产数据库
说来惭愧，作为一个在传统 MySQL 技术栈里"泡"了好几年的开发者，我对国产数据库的认知长期停留在"听说过"的阶段。直到今年公司启动信创改造评估，技术选型会议上第一次被问到"有没有了解过 TiDB"，我才意识到——是该认真看看这些国产数据库了。
信创，即信息技术应用创新，核心目标是实现关键信息基础设施的自主可控。在数据库领域，这意味着我们需要找到既能替代 Oracle/MySQL，又在性能、稳定性和生态上经得起考验的国产方案。带着"到底靠不靠谱"的疑问，我开始了 TiDB 的探索之旅。
说实话，一开始我是带着偏见的。毕竟这些年也见过不少"国产替代"产品，有的只是换了个壳。但深入了解了 TiDB 之后，我发现自己错了——这不只是一个"替代品"，而是一个在设计理念上就往前走了一步的数据库。
初印象：兼容 MySQL 这件事，比我预想的认真
接触 TiDB 的第一件事，是翻官方文档。让我意外的是，TiDB 的文档站（https://pingkai.cn/docs/tidb/stable）内容非常完善，中文文档质量相当高，这一点对国内开发者太友好了。
文档里反复强调的一个核心特性是 MySQL 兼容。说实话，一开始我并不以为然——"兼容"这个词在各种产品宣传里被用烂了，兼容到什么程度才是关键。于是我决定亲手验证。
用 TiUP（TiDB 官方部署工具）在本地起了个测试集群，整个过程出奇地简单：
# 安装 TiUP
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
# 一键启动本地测试集群
tiup playground
不到两分钟，一个完整的 TiDB 集群就跑起来了。然后我用平时连接 MySQL 的 Navicat 直接连上去——端口 4000，用户名 root，没有密码——居然直接就连上了。（较新版本会生成临时初始密码，需从日志中获取。）
接下来的体验更让我惊喜：建库建表、增删改查、事务、索引、视图……我把自己平时在 MySQL 上跑的 SQL 脚本原封不动地扔进去，绝大部分都能直接执行。当然也有一些差异，比如 TiDB 对存储过程的支持有限（这在使用中需要注意），但从总体兼容度来说，已经远超我的预期。
这意味着什么？对于 MySQL 用户来说，迁移到 TiDB 的学习成本非常低。 你不需要从头学一套新的 SQL 方言，已有的业务代码几乎可以直接跑——这在信创替代场景下是一个巨大的优势。
深入：当"分布式"不再只是一个概念
兼容 MySQL 是 TiDB 的"面子"，而分布式架构才是它的"里子"。作为一个之前只用过单机数据库的人，TiDB 的架构设计给了我很多"原来还能这样"的时刻。
存算分离：第一次理解"无状态"的价值
在 MySQL 的世界里，计算和存储是耦合在一起的——一个 MySQL 实例既负责处理 SQL，又负责存储数据。扩容？加配置。再不够？分库分表。分库分表的复杂度，经历过的人都懂。
TiDB 把这个架构拆开了：
- TiDB Server：只负责 SQL 解析、优化和执行，不存任何数据。你可以把它理解成"纯计算节点"，想加多少加多少，彼此之间完全对等。
- TiKV：专门负责存储数据的分布式 Key-Value 引擎。数据自动分片（Region），自动多副本，自动负载均衡。
- PD（Placement Driver）：集群的"大脑"，管理元数据、调度数据分布、分配全局时间戳。
第一次看到这个架构时，我的反应是："这不就是微服务架构的思想吗？"把单体拆成独立的服务，各自独立扩展。在应用层我们这么做已经很多年了，但数据库领域真正做到存算分离的产品并不多。TiDB 把这个理念落地了，而且做得相当彻底。
这个设计带来的直接好处是：扩容时不再需要复杂的数据迁移。TiDB Server 扩容就是加节点，流量自动分摊；TiKV 扩容也是加节点，PD 会自动把数据 Region 调度到新节点上。整个过程对业务透明，不需要像分库分表那样手动设计分片规则。
Region：理解分布式存储的基本单位
TiKV 中数据以 Region 为基本单位进行管理，这是理解 TiDB 存储层的关键概念。在较早版本中，每个 Region 默认约 96MB；从 v8.4.0 开始默认调整为 256 MiB，负责存储一段连续 Key Range 的数据。
让我用一个类比来理解：如果把整个数据库比作一本很厚的书，Region 就是这本书的"章节"。当一个章节太厚了（超过阈值），它会自动拆分成两个章节；当两个相邻章节太薄了，它们会自动合并。这个拆分和合并的过程完全自动，由 PD 统一调度。
每个 Region 默认有 3 个副本，分布在不同的 TiKV 节点上，通过 Raft 协议保证一致性。这意味着即使一个节点挂了，数据也不会丢失——另外两个副本还在，集群会自动选出新的 Leader 继续提供服务。
作为之前只接触过 MySQL 主从复制的人，这个设计的优雅程度让我印象深刻。MySQL 的高可用需要借助 MHA、Orchestrator 等外部工具，配置复杂且容易出问题；而 TiDB 把高可用内置到了存储引擎层，通过 Raft 协议自动完成故障检测和 Leader 切换。
HTAP：一份数据，两种读法
TiDB 最让我觉得"有意思"的特性是 HTAP（Hybrid Transactional and Analytical Processing）。
以前做报表分析，标准套路是：OLTP 数据库（MySQL）→ ETL → OLAP 数据仓库（ClickHouse / Hadoop）。数据要搬一次，延迟几个小时是常事，还得维护两套系统。
TiDB 的方案是在 TiKV（行存）旁边加了一个 TiFlash（列存）节点。TiFlash 通过 Raft Learner 协议异步复制 TiKV 的数据，延迟通常在毫秒级——同一份数据，在 TiKV 里是行式存储（适合事务处理），在 TiFlash 里是列式存储（适合分析查询）。
TiDB 的优化器会自动判断：如果是一条简单的点查，走 TiKV；如果是一个复杂的聚合分析，走 TiFlash。用户不需要关心数据从哪里读，优化器帮你做决策。
当然，作为新人我也有一些理性的思考：HTAP 并不是银弹，TiFlash 会额外占用存储资源，实时同步也会带来一定的写入开销。在资源有限的场景下，是否需要 TiFlash 需要根据实际业务负载来评估。但不可否认的是，对于很多中小型企业来说，"一套系统搞定 OLTP + OLAP"的方案确实大大降低了系统复杂度。
实操：第一次在 TiDB 上跑业务
理论理解再多，不如亲手跑一遍。我在本地部署的 TiDB 集群上做了一些实际操作，这里分享几个让我印象深刻的体验。
体验一：SQL 兼容性验证
我把一个之前在 MySQL 上运行的订单管理模块的建表语句和业务 SQL 直接在 TiDB 上执行：
###sql
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_RANDOM,
order_no VARCHAR(32) NOT NULL,
user_id BIGINT NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status TINYINT DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id),
INDEX idx_status (status)
);
这里用到了 TiDB 的 AUTO_RANDOM 特性——它代替了 MySQL 的 AUTO_INCREMENT，自动生成随机 ID 来避免写入热点。这是一个很小但很贴心的设计，说明 TiDB 团队确实在思考分布式场景下的实际问题。
业务层面的 CRUD、JOIN、子查询、事务……基本上都能直接跑通。少数需要注意的点：
- TiDB 的自增 ID 行为和 MySQL 不完全一致（分布式环境下无法保证严格连续）
- 部分 MySQL 特有语法（如
GROUP_CONCAT的某些用法）有细微差异
- 存储过程和触发器目前不支持
但总体来说，兼容性达到了"业务代码几乎不用改"的程度，这对信创迁移场景来说非常关键。
体验二：感知 Region 调度
插入一批测试数据后，我通过 TiDB Dashboard（PD 内置的 Web 管理界面）观察了 Region 的分布情况。可以直观地看到数据是如何被自动分片到不同 TiKV 节点上的，以及 PD 是如何在节点间做负载均衡的。
这种"看到分布式系统在运作"的感觉很奇妙——在 MySQL 的世界里，你永远看不到这些，因为所有数据都在一个实例里。而在 TiDB 中，数据是活的，它在节点间流动、分裂、合并，一切都在自动运转。
体验三：模拟节点故障
我手动停掉了一个 TiKV 节点，然后观察集群的行为：Dashboard 上该节点状态变为 Down，对应 Region 的 Leader 自动切换到其他节点的副本上，业务查询几乎没有中断。恢复节点后，数据自动追平，Leader 可以再切回来。
这个体验对于一直使用 MySQL 主从架构的我来说冲击很大——高可用不需要外部工具，不需要人工干预，内置在数据库内核里。
思考：TiDB 适合什么场景，不适合什么场景
作为一个刚接触 TiDB 的新人，我也尝试理性地思考它的适用边界：
适合的场景：
- 数据量大、单机 MySQL 扛不住，但又不想搞分库分表的场景
- 需要同时做事务处理和实时分析（HTAP）的业务
- 对高可用和数据一致性有较高要求的金融、政企场景
- 信创替代场景下，希望从 MySQL 平滑迁移的团队
需要谨慎的场景：
- 数据量不大（几十 GB 以内），单机 MySQL 完全够用的场景——TiDB 的分布式架构会带来额外的资源开销
- 强依赖存储过程、触发器等 MySQL 特有功能的系统
- 对单机极致性能（极低延迟）要求极高的场景——分布式架构的网络开销是客观存在的
没有银弹，选型永远是权衡。TiDB 在分布式、高可用、水平扩展和 HTAP 方面有明显优势，但也带来了部署复杂度和资源开销的增加。理解这些 trade-off，比盲目跟风更重要。
新人的几条建议
如果你也像我一样，正在从 MySQL / Oracle 转向了解 TiDB，以下几条建议可能对你有帮助：
- 从 TiUP playground 开始：不要一上来就折腾集群部署，先用
tiup playground在本地跑一个测试集群，10 分钟就能上手。
- 先跑 SQL，再学原理：把你在 MySQL 上的业务 SQL 拿来跑一遍，感受兼容性。遇到不兼容的地方，查阅官方文档，这些差异本身就是理解 TiDB 的入口。
- 善用 TiDB Dashboard：这是了解 TiDB 内部运作的最好窗口。Region 分布、热点调度、慢查询分析，都能在这里直观地看到。
- 加入社区：TiDB 社区（pingkai.cn/tidbcommunity）非常活跃，AskTUG 论坛上有大量实战经验分享。遇到问题不要自己闷头查，社区小伙伴都很热心。
- 保持独立思考：不要被"国产替代"的标签牵着走，也不要因为"分布式"的概念就觉得高深莫测。把它当成一个工具来理解——搞清楚它解决了什么问题、怎么解决的、有什么代价——这就够了。
写在最后
从最初的"国产数据库到底行不行"的怀疑，到亲手部署、跑 SQL、观察 Region 调度、模拟故障恢复，我对 TiDB 的认知经历了一次完整的转变。
TiDB 并不是一个完美的数据库——它有自己的适用边界和资源开销。但它的架构设计确实让人眼前一亮：存算分离、Multi-Raft、HTAP……这些不只是技术名词，而是真正解决了实际问题的工程方案。在信创的大背景下，TiDB 给了我一种"国产数据库确实在认真做"的踏实感。
对于正在观望的朋友们，我的建议很简单：别只是听别人说，自己动手试一试。 tiup playground 两分钟就能跑起来，也许你也会和我一样，对国产数据库有新的认识。