企业官网建设流程全解析

3月14日，TiDB社群在长沙搞了一场线下聚会，主题叫“数智湖南”。我本来以为就是一场普通的技术沙龙，结果到了现场才发现，来的几乎都是各行业正在做数据库国产化升级的一线团队——零售、医疗、金融、交通、智能制造，一个不落。大家聊的内容也很实在，不是“国产化该不该做”这种务虚话题，而是“存量Oracle怎么迁”“大促峰值怎么扛”“TiDB和MySQL语法差异怎么处理”这种能直接带回公司落地的经验。

这篇文章我就以这场活动为引子，把现场聊到的、会后复盘的技术点系统地梳理一遍。核心围绕TiDB这个开源分布式数据库在国产化升级中的定位、分行业落地打法、迁移实操路径，以及几个我在生产环境里踩过的坑。不管你是正在做数据库选型评估，还是已经进入迁移阶段，这篇都应该能给你一些可以直接抄作业的东西。

1. 为什么偏偏是长沙：一场社群聚会让国产化不再是口号

先聊聊这场聚会本身的氛围。活动场地不算大，但来得人很齐。我旁边坐的是某连锁零售品牌的数据库负责人，他们正在把会员系统和订单系统从Oracle往TiDB上搬；对面是一位做智慧交通的架构师，聊的是卡口数据和轨迹查询的存储改造；还有几位来自本地三甲医院信息科的老师，关心的是电子病历系统的高可用和容灾。

这和湖南本地的产业结构高度相关。零售连锁、工程机械制造、医疗资源、交通物流，这些行业在湖南都很密集，而这些行业恰恰是传统数据库存量最深、国产化升级需求最迫切的地方。大家在一个屋子里聊同一件事，就是存量系统怎么平稳地换到国产分布式数据库上。

为什么大家不约而同在关注TiDB？活动现场有一个共识：数据库国产化升级，最难的不是数据库本身，而是“换了之后业务还能不能正常跑”。TiDB之所以被反复提起，根本原因是它对MySQL生态的高度兼容——应用层改动小、DBA上手快、周边工具能复用。这意味着迁移的边际成本被大幅压缩，不像以前那种从Oracle迁到新平台要重写SQL、重做报表，甚至整个研发团队重新培训。

现场让我印象很深的一段对话，是一位做金融系统的工程师讲的：他们内部做国产化选型测评，把TiDB和另一款国产数据库放在同样的硬件上跑同一套压测脚本，结果TiDB在并发写入和弹性扩容两个维度上优势非常明显。但他也强调了一句大实话——跑分只是一部分，真正决定选型的，是团队有没有能力接得住这套分布式架构。

这话说到了根子上。TiDB不是简单的“MySQL换皮”，它的分布式内核决定了运维方式、故障处理方式、容量规划方式都跟单机数据库不一样。所以这篇文章我不会只吹优点，也会把运维层面的代价和踩坑细节讲透。这样你评估的时候，心里才有一本完整的账。

2. 数据库国产化的本质：换引擎不是换皮肤

2.1 TiDB到底是什么样的数据库

很多人第一次接触TiDB，会把它当成一个“能水平扩展的MySQL”。这个说法方向对，但不完全准确。TiDB的架构是由多个组件协同工作的：TiDB Server负责SQL解析和优化，是无状态的，可以随便扩；TiKV负责真正的数据存储，数据按照Region切片分布在多个节点上，每个Region默认有多副本，通过Raft协议保证强一致；PD（Placement Driver）是整个集群的调度中心，负责Region的分布、负载均衡和故障恢复；还有一个TiFlash，是列式存储的副本，专门跑分析型查询。

这个架构带来的能力，是单机数据库很难给的：扩容就是加节点，数据会自动重分布，不需要手工分库分表；副本挂掉一个，Raft会自动选主恢复，应用侧基本无感；在线事务和分析查询可以跑在同一套数据上，不需要像传统架构那样弄一套ETL把数据搬到数仓。

活动现场有一位老DBA用了一个很贴切的比喻：TiDB像一个“自带调度中心的大型仓库”，货物（数据）自动分布在多个货架（TiKV节点）上，哪个货架满了，调度中心会自动把货挪到空的货架上。你要扩容，就多租一个货架，调度中心会自动安排。这个比喻虽然粗糙，但对于理解TiDB的核心价值——弹性伸缩和自动化运维——非常到位。

2.2 兼容性红利：保住团队十年积累

聊国产化，最容易被低估的是“团队技术资产的保值”。一家公司用了十年MySQL，积累的是无数SQL写法、监控脚本、备份方案、排查经验。如果换一个完全不兼容的国产数据库，这些资产全部作废，团队要重新学一套新东西，这个隐性成本比买软件的钱高得多。

TiDB在这方面占了很大的便宜。它兼容MySQL协议，意味着你现有的MySQL驱动、连接池、ORM框架基本不用改；常用的SQL语法，包括JOIN、子查询、窗口函数、公共表表达式，TiDB都能跑。更关键的是，团队里那些写了多年MySQL的工程师，看TiDB的慢查询日志、执行计划、系统表，会感觉非常亲切，上手成本被压到了最低。

现场有位做医疗系统的工程师分享了他们实测的结果：一个存量的业务系统，大概几千条SQL语句，在TiDB上做兼容性测试，直接能跑通的比例超过95%；剩下那不到5%，基本都是Oracle语法遗留，比如ROWNUM、CONNECT BY这类MySQL系本就罕见的东西，改造成本也可控。

2.3 一套库干两件事：HTAP的独特价值

传统架构里，在线事务（OLTP）和在线分析（OLAP）通常是两套系统。业务库负责写入和查询，数据通过定时同步流入数据仓库或专门的分析库。这套架构稳定，但有一个绕不开的痛点：时效性。T+1的同步，意味着今天的报表看不到今天上午的数据。你在零售行业会发现，“实时报表”和“高峰期的在线交易”这两个需求放在一起时，传统架构很难同时满足。

TiDB的HTAP能力就是冲着这个痛点去的。同一份数据，TiKV处理高并发的事务读写，TiFlash列式副本负责分析查询。应用层不需要改任何SQL，只需要把分析类查询路由到TiFlash，就能在毫秒级拿到聚合结果，数据实时性跟业务完全同步。

活动现场一个做零售的企业分享了一个很具体的场景：大促期间，运营要随时看实时销售额、库存水位、门店Top10商品排名。以前他们靠业务库加定时任务算，一算就锁表，影响正常下单。迁移到TiDB之后，订单数据直接落在TiKV，分析查询走TiFlash，两边互不干扰。运营要看的实时大屏，直接从TiDB出数，中间省掉了一整套数据同步链路。

2.4 什么样的系统适合纳入TiDB替换范围

这也是现场被问得最多的问题。我的判断标准很简单，四条：

1. 数据量或并发到了单机数据库的瓶颈。比如单表过亿，或者峰值QPS持续走高，MySQL已经要靠分库分表撑着了。
2. 对高可用、数据强一致有硬要求。业务不允许丢数据，宕机恢复时间要分钟级。
3. 业务具备分布式改造的接受度。不是说完全不改，但改动量要可控，最多是SQL语句级的小改，而不是架构级重写。
4. 团队有基本的分布式系统认知。哪怕DBA以前只玩过MySQL，只要愿意学习Region、Raft、PD这些核心概念，TiDB是能接住的。

反过来，如果系统数据量几个GB，并发几百，高可用要求也不高，那完全没必要上TiDB。单机数据库加主从复制，成本更低，运维更简单。数据库选型最忌讳跟风，得先看清楚自己的边界在哪里。

3. 零售、医疗、金融、交通、制造：五类业务在TiDB上的落地打法

活动现场最受欢迎的是分行业交流环节。每个行业的业务模型不一样，落到TiDB上的技术打法差异很大。我把现场讨论的要点和我的实践经验合并在一起，逐个行业拆一遍。

3.1 零售：大促峰值弹性扩容是核心诉求

零售行业的核心矛盾，是流量波动剧烈。日常订单量级和双十一大促的订单量级可能相差几十倍。传统MySQL架构应对这种峰值，要么提前扩容硬件，要么分库分表，但峰值过去了，资源就闲置了。

TiDB的弹性扩容能力，天然契合这个场景。大促前给集群加几个TiKV节点，数据自动均衡，容量和写入吞吐跟着涨；大促结束，节点可以缩回去，成本跟着业务走。这个操作在TiDB里就是加节点、等待均衡、删节点三步，不需要动业务代码。

但零售行业容易踩一个坑：热点写。用户下单时，订单表如果用的是自增主键，那么所有写入都会集中在最后一个Region上，形成单一热点。现场有位架构师分享了一个很实用的解法——订单表的主键改用AUTO_RANDOM，或者用业务订单号直接做主键，让TiDB把写入压力打散到不同的Region上。示例建表语句很简单：

CREATE TABLE `orders` ( `id` BIGINT NOT NULL AUTO_RANDOM, `order_no` VARCHAR(32) NOT NULL, `store_id` INT NOT NULL, `customer_id` BIGINT NOT NULL, `amount` DECIMAL(12,2) NOT NULL, `status` TINYINT NOT NULL DEFAULT 0, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

另一个零售高频场景是商品和门店维度的实时分析。比如运营要看“华东区今天卖得最好的100个SKU”，这种查询很适合让优化器把分析SQL路由到TiFlash列存节点，在线交易和分析互不干扰。

3.2 医疗：7×24高可用与数据强一致是底线

医疗行业对数据库的要求，最核心的四个字是“不能出事”。电子病历、门诊挂号、药库管理，任何一个环节出现长时间不可用，影响的不只是业务，还有医疗安全。宕机恢复时间、数据零丢失，这些都是硬指标。

TiDB通过多副本加Raft协议来满足这个要求。数据写入时，必须有多数派副本确认，才算提交成功。这意味着单副本故障不会丢数据，也不会中断服务。如果做两地三中心部署，PD支持自定义副本位置，可以规定机房A放两副本、机房B放一副本，在保证安全的同时控制异地容灾成本。

医疗行业还有一个容易被忽略的需求：数据生命周期管理。电子病历按规定要保存多年，但活跃查询只集中在近期数据。这种场景适合用TiDB的分区表能力，按时间维度做Range分区，旧数据可以整体归档甚至DROP分区，而不影响在线业务。分区表的建表方式如下：

CREATE TABLE `medical_records` ( `record_id` BIGINT NOT NULL, `patient_id` BIGINT NOT NULL, `visit_time` DATETIME NOT NULL, `diagnosis` TEXT, `attending_doctor` VARCHAR(64), PRIMARY KEY (`record_id`, `visit_time`) ) PARTITION BY RANGE (YEAR(`visit_time`)) ( PARTITION p2020 VALUES LESS THAN (2021), PARTITION p2021 VALUES LESS THAN (2022), PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION pmax VALUES LESS THAN MAXVALUE );

3.3 金融：核心链路怎么敢用分布式？

金融行业是对数据一致性要求最苛刻的领域，没有之一。账务系统里的一笔转账，涉及账户扣减、交易流水、对端入账，任意一步出错或者数据丢失，后果都很严重。所以金融团队问的第一个问题往往是：分布式数据库能保证强一致吗？

TiDB的答案是能的，而且机制上是可以验证的。TiDB的分布式事务模型基于Percolator，结合PD分配全局时间戳，能保证跨节点、跨表的事务ACID特性。也就是说，你在TiDB里执行一个涉及多张表的大事务，要么全部成功，要么全部回滚，不存在中间状态。配合多副本Raft，写入一旦返回成功，就意味着数据已经在多数派节点落盘，不会因为单个节点宕机而丢失。

金融行业另一个需求是审计与风控。传统上，交易流水和风控分析是两套系统，流水进业务库，风控跑数仓，中间有分钟级到小时级的延迟。在TiDB上做HTAP改造之后，风控分析的实时性可以大幅提升，大额交易、异常模式识别不再是事后发现，而是可以做到近乎实时的行为监控。当然，金融业务对过审极其严格，现场做分享的工程师也提醒：核心账务系统迁移不是一蹴而就的，他们的策略是先拿风控、征信查询、报表这类非账务核心系统试点，跑稳定了再往核心链路推进。

3.4 交通：高并发写入与轨迹查询的双重考验

交通行业有一个很典型的场景：早晚高峰的卡口过车数据。一个中型城市每天产生几千万条过车记录，每一条都要完整落库，同时还要求支持按车牌、时间、卡口条件组合查询。这种高并发写入加复杂查询的组合，对数据库的写入吞吐和查询性能都提出了很高的要求。

TiDB在写入侧的打法是水平扩展。几个亿的过车数据，在TiDB里会被自动切片成大量Region，分散在多个TiKV节点上并行写入。写入压力大，就加TiKV节点，吞吐线性增长。查询侧的打法是用好TiFlash。轨迹查询往往要做车牌号加时间的聚合统计，这类分析SQL在TiFlash的列式存储上跑，比在TiKV上走二级索引再回表的方式快很多倍。

现场还有一个有代表性的讨论：实时路况大屏。城市交通的实时路况展示，数据源是海量GPS轨迹上报。很多团队的第一反应是上Kafka加流计算，但从业务端看，其实只需要拿到“最近五分钟，每条路段的车流量”。流量没那么大的城市，直接用TiDB加上定时聚合，成本远低于搭一套实时数仓。

3.5 智能制造：IoT数据与质量追溯的长期战场

智能制造的数据特点，一是采集密度高，二是历史追溯深。一台设备每秒上报一条状态数据，一个工厂上千台设备，一天就能产生上亿条数据；而质量追溯往往要回溯几个月前的某个批次的完整生产记录。

IoT数据写入TiDB，要注意批量插入的方式。上一篇文章提过大事务限制，这里再强调一次：TiDB的单事务默认上限是100MB，执行时间默认不能超过一小时。如果一边采集一边逐条insert，不仅性能差，还可能偶发事务超时。正确的做法是攒批插入，比如每1000条数据一个事务，既压低了事务提交频率，又避免了单事务过大。

质量追溯场景适合用TiDB的全局索引能力。比如按批次号、设备编号、生产日期组合查询，即使在几十亿行的表上，只要索引设计合理，查询响应都能稳定在百毫秒级。这在过去的MySQL分库分表架构里是很头疼的——数据被拆到几十个库，跨库查询要么走中间件，要么起临时任务汇总，效率极低。TiDB从设计上就避免了这个问题，全局索引天然支持跨节点查询。

4. 迁移上车：从存量数据库到TiDB的一次完整手术

聊完了行业打法，回到最核心的工程问题：存量系统怎么迁到TiDB。这一步做不好，前面的技术评估全是白搭。我从现场的分享和个人的实操经验里，整理了一条完整的迁移路径。

4.1 迁移前评估：先摸清家底再动刀

第一步是盘点存量资产。你需要回答三个问题：有哪些数据库实例？每个实例上有哪些业务？各自的数据量、表结构、SQL特征是什么？

这里面最花时间的不是数据量统计，而是SQL兼容性分析。建议把业务的SQL日志捞出来，按语句指纹分类，统计每条SQL在TiDB上能否直接执行。我们当时是写了一个脚本，从慢查询日志和审计日志里提取出SQL样本，跑在TiDB的测试集群上，自动归类为“完全兼容”“语法兼容但行为待确认”“完全不兼容”三档。三档的比例决定了这个系统的迁移成本。

还有一个容易被忽略的点：数据库账号权限和运维脚本。MySQL的授权模型跟TiDB存在一些细节差异，比如TiDB的用户权限是全局的，粒度没有MySQL那么细。原来那些按账号做权限隔离的脚本，迁移后要做对应的调整，否则上生产环境第一天就可能遇到权限报错。

4.2 工具链：从导出到实时同步的完整闭环

TiDB官方提供了一整套数据迁移工具，这一点比很多闭源国产数据库要省心得多。我按用途列一下：

• Dumpling：数据导出工具，支持并发导出，性能比mysqldump好得多，适合做全量数据导出。
• TiDB Lightning：数据导入工具，专门针对TiDB做过优化，支持并行导入，能在较短时间内把几十GB甚至几TB的数据灌进TiDB。
• DM（Data Migration）：数据同步工具，支持从MySQL/MariaDB实时同步到TiDB，可以做全量加增量的一致迁移。如果你的源库本身就是MySQL系，DM是最顺畅的一条路。
• TiCDC：TiDB的变更数据捕获组件，可以实时将TiDB的binlog变更推送到Kafka或下游数据库，主要用于迁出和双写场景。

如果是Oracle存量，常见路径是先用OGG或自研ETL工具把数据转换成MySQL兼容格式，落到中间库，再接DM做增量同步。这个过程会比MySQL直迁多一层，但好处是业务侧几乎不需要改数据模型。

4.3 全量同步、增量追平、灰度切流：三步走的细节

全量同步阶段，要注意的是同步期间的停业时间。如果要求不停机迁移，一般是先跑全量，全量导入完成后，再用DM切换增量模式。增量追平的意思是，让TiDB的数据始终跟着源库走，两边数据延迟逐渐缩小到秒级甚至毫秒级。

确认增量追平之后，就到了最关键的灰度切流。我的建议是分四步：

1. 先切只读流量。把报表、查询类业务指向TiDB，观察查询耗时和正确性。
2. 再切非核心写流量。挑一个风险可控的业务模块，开启双写或直接切写，重点盯数据一致性和事务成功率。
3. 数据校验通过后，切核心写流量。这里要提前准备回滚预案，见下文。
4. 老库保留观察。至少跑一个完整的业务周期（比如一周），确认TiDB侧没有隐患，再启动老库下线流程。

4.4 回滚方案：切流最怕的是开弓没有回头箭

很多团队在迁移时最焦虑的就是：切到TiDB了，万一有问题，回不去了怎么办？我的经验是，回滚方案要在切流之前就准备好，而不是切完再想。

最稳妥的做法是，源库在切换窗口内保持“只读但不杀”。也就是说，业务流量切到TiDB之后，源库继续保留，同时让DM的反向同步方向做起来——如果TiDB侧有写入变更，会通过TiCDC实时回流到源库。这样两边数据始终是对齐的，万一TiDB侧发现严重问题，业务可以在分钟级切回源库，数据不缺不漏。

当然，反向同步的代价是额外的一跳延迟和资源开销，所以观察期一般不会拉太长。我们的经验是，TiDB侧稳定跑一周，期间修复了所有已经暴露的问题，反向同步就可以断开了。断开的时机选择业务低峰期，断开后源库保留归档权限，TiDB正式成为生产主库。

5. 踩过才懂：国产化落地最痛的几个生产细节

这一节全部来自生产环境的真实教训。每一项都是我们或现场同行踩过坑之后，用时间和故障换来的经验。写出来，是希望你能少走这些弯路。

5.1 自增主键热点：TiDB压力最大的一课

之前在零售章节提过，这里展开讲。MySQL时代，自增主键是最主流的写法，但在TiDB里，这个习惯可能演变成性能瓶颈。原因是TiDB的数据按主键排序切片存储，自增主键连续增长，意味着新写入的数据永远落在最后一片Region上。所有并发写入集中在一个节点，其他节点空闲，集群整体利用率上不去。

解决办法有两个：一是主键改用AUTO_RANDOM，让TiDB自动生成分散的主键值；二是放弃主键的随机性要求，改用业务字段做主键，比如订单号、设备ID。需要注意，AUTO_RANDOM在建表时就要指定，后续ALTER TABLE改不了。所以迁移建表阶段就要想清楚这个字段策略。

5.2 大事务与GC的相爱相杀

TiDB对大事务是有明确限制的，单事务默认不能超过100MB，执行时间默认不能超过1小时。如果业务里有一把梭的批处理脚本，比如每天凌晨一次性UPDATE全表，很容易触发报错。更麻烦的是，长时间运行的事务会和TiDB的GC（垃圾回收）机制产生冲突。

GC的作用是清理历史版本数据，它有安全点保护机制。如果一个事务运行时间太长，超出了GC安全点的保护范围，就会报“GC life time is shorter than transaction duration”的错误。这不是偶发问题，而是机制性的——TiDB为了保持MVCC读一致，保留了历史版本，但如果历史版本积累过多，又会拖慢读写。

解决办法是把批量操作拆碎。一次更新十万条，拆成每次一千条的小事务，间隔几十毫秒提交。这样既能保持业务逻辑完整，又不会触发大事务限制，也不会和GC打架。

5.3 字符集、连接参数与隐式转换

这类问题隐蔽性极强，往往是业务高峰时突然出现，排查半天才发现是底层配置问题。迁移到TiDB后，三个高频坑点你要提前检查：

一是字符集排序规则。MySQL 8.0默认的utf8mb4_0900_ai_ci，跟TiDB支持的排序规则存在差异。如果业务原有的建表语句指定了特定排序规则，迁移后虽然能建表，但查询结果排序可能跟预期不一致。建议迁移时统一成utf8mb4_general_ci或utf8mb4_bin，先保证行为一致。

二是JDBC连接参数。TiDB兼容MySQL协议，但JDBC连接串里如果带了一些MySQL特有的参数，比如useSSL=false之类的，在TiDB侧可能表现不同。最稳妥的方法是连接参数尽量精简，先跑通业务，再逐步补齐安全相关的配置。

三是隐式类型转换。MySQL里数字和字符串比较时，会有隐式转换，TiDB在这方面的行为跟MySQL基本一致，但边界场景可能不同。比如WHERE phone = 13800138000，phone是VARCHAR类型，右侧是INT，两边引擎的处理结果可能不一样。迁移前最好针对所有条件查询的字段类型做一遍核对，避免数据在类型边界上出问题。

5.4 容量规划：三副本和TiFlash都在吃你的磁盘

很多团队在计算TiDB容量时，只按源库数据量做乘法，结果扩容预算严重超支。这里要算清一笔账：TiDB默认三副本，意味着你的原始数据量要乘以3，这是第一层；如果开了TiFlash列存副本，TiFlash的副本数量单独计算，这是第二层；再加上日常的MVCC历史版本、事务日志的开销，整体存储用量大约是源库逻辑数据量的4到6倍。

这笔账在项目立项时就要算清楚并汇报给管理层，否则上线半年后磁盘见底，再申请扩容预算，流程上会很被动。

5.5 慢查询排查：用好TiDB Dashboard这张地图

TiDB的慢查询定位，体验比MySQL好很多。MySQL时代定位慢查询，最常用的手段是看慢查询日志和执行计划，信息是割裂的。TiDB的Dashboard把所有信息都汇总到了一张图里：慢查询列表、执行计划、扫表量和内存占用、甚至关联的SQL语句和表结构都能直接看到。

我的建议是，迁移完成后的第一个月，每天固定时间看一次Dashboard的Top SQL列表。大量成功案例里，第一批被揪出来的慢查询，一半以上是“原MySQL里尚可接受，迁到分布式环境后放大”的语句——比如不带WHERE条件的全表扫描，或者关联了十几张表的复杂视图。这类SQL在单机环境也许能靠硬件硬顶，但在分布式环境里，跨节点的数据扫描会把问题放大好几倍，必须尽早改写。

6. 会后的一点实话：TiDB不是万能钥匙

活动最后有个环节是开放讨论，主持人问了一个问题：TiDB有没有不适合的场景？现场安静了几秒，然后大家开始轮流吐槽。我觉得这些吐槽非常有价值，比任何宣传材料都真实。

第一个公认的短板是小规模系统。如果你整个系统的数据量连100GB都不到，并发也就几百，高可用要求可以通过主从复制满足，那就没必要上TiDB。分布式系统带来的节点通信开销、运维复杂度，在这个体量下是纯负担，性价比很低。

第二个是重度存储过程或触发器依赖的系统。TiDB对存储过程的支持能力远比MySQL有限，触发器更是原生不支持。如果业务逻辑大量封装在触发器里，迁移时要先把这些逻辑改为应用层实现，这个改造量可能比想象中大得多。

第三个是极端的多表关联查询。TiDB的优化器已经很强，但跨节点的表连接，特别是三张以上大表做复杂关联，性能仍然无法和专门的分析型数据库相比。如果你的核心业务长期跑着这种查询，建议把分析负载放到TiFlash或者专门的数据仓库里，TiDB更适合做高并发的事务处理和中等复杂度的分析。

根据我个人做国产化迁移的经验，还有一个容易被低估的点：资源投入的评估。很多人以为TiDB是开源的，软件不花钱，整体成本就低。实际上，三副本带来的硬件成本、Tiflash额外存储、升级后的监控告警体系、团队的学习和运维成本，加起来的总拥有成本并不低。国产化升级不是一次买断，是一个持续投入的工程。

但我也要说句公道话：框架搭对了，TiDB确实是目前国产化升级路径里，让人最踏实的数据库底座之一。它开源的架构、活跃的社群、完整的工具链，意味着你在生产环境里遇到的问题，大概率别人也遇到过，TiDB官方和社区都能给出可参考的解法。这一点，恰恰是很多闭源国产数据库给不了的。

这次在长沙，我最大的收获不是某个具体的技术方案，而是亲眼看到了一批不同行业的工程师，正在踏踏实实地把数据库国产化做成真事。零售、医疗、金融、交通、制造，每个行业都有自己的难点，但大家都在用同一个引擎、同一套方法论往前走。这让我觉得，数据库国产化升级这件事，正在从“要不要做”的技术评估阶段，切换到“怎么做得更稳”的工程落地阶段。接下来，就是看谁能在生产环境里跑得更久、更稳了。