这两段录播发布于 2023 年 3 月。产品版本、个人经历与观点均为当时情况。
杜振强当时在 PingCAP 从事行业解决方案工作，此前在电商和互联网公司长期接触数据库。这场分享先解释 TiDB 想解决的问题，再进入云上架构与适用场景；后半场则从 ChatGPT 聊到出海、职业选择、开源和商业化。两段录播合计约 83 分钟。
数据库的发展，是业务规模与使用方式不断变化的结果
他从关系数据库的发展讲起：商业数据库、开源关系数据库，解决了不同阶段的数据管理问题；互联网与移动互联网带来的增长，又让数据量、吞吐和分析需求逐渐超出单机能够方便承载的范围。
行业并不是一次就找到统一答案。大数据体系承担更大规模的分析，NoSQL 探索不同数据模型与扩展方式，业务团队也通过分库分表继续使用已有关系数据库。每种方法都解决一部分问题，同时带来新的使用和维护成本。
分享将 NewSQL 放在这条演进线上理解：希望把关系数据库的事务能力与分布式系统的水平扩展结合起来。与此同时，基础设施从大型机、自建服务器逐渐走向云服务，数据库也要重新考虑部署、资源管理和交付方式。这是后面讨论 TiDB 和云原生的起点。
先分清公司、数据库与不同组件
杜振强先澄清 PingCAP 与 TiDB 的关系，再介绍团队从开源方式发展产品的路径。他提到社区、用户和行业关注度，作为当时产品发展的背景。更核心的技术目标，是支持事务与水平扩展，在节点故障、数据增长和不同负载下保持可管理性。
他并没有把数据库的定位只放在数据容量上，也比较了事务型访问与分析型访问的差异。分布式系统需要网络通信，不能假设一次访问与单机内存操作具有相同成本；分析查询又会受列存、并行计算和查询复杂度影响。录播中的延迟与容量数字属于示意比较，判断实际场景仍需要对应的负载和部署条件。
他的比较横跨两条轴线：一条是单机能装下多少数据、能承担多少并发；另一条是用户愿意为一次查询等待多久。典型事务请求追求较低延迟，传统大规模分析可能接受更长处理时间。TiDB 希望在规模扩大后仍处理事务，并让一些分析更快进入结果阶段；代价是分布式事务离不开网络，不会拥有单机进程内访问的同样开销。选型时不能只用“更大容量”掩盖延迟差异。
TiDB 处理 SQL，TiKV 与 TiFlash 承担不同的数据访问需求
架构讲解从应用入口开始。应用通过兼容 MySQL 协议的接口访问 TiDB，SQL 层负责解析、计划和执行协调，再向存储层取得需要的数据。计算层与存储层分开，使它们可以分别考虑扩展。
TiKV 提供行式存储；TiFlash 提供列式副本和分析能力。两者承担的工作不同，不能把整个系统理解为把一台数据库简单复制到多台机器。分析型查询与面向单条或少量记录的访问，需要不同的数据组织与执行方式。
从应用看，入口仍是 SQL。比如按订单号查一笔订单，优化器更可能选择适合点查的行存；若按日期和状态汇总大量订单，则可能选列式副本和并行计算。用户不用为两条路径分别维护一套应用访问代码，但数据库内部必须处理数据副本、执行计划及资源干扰。这是“混合事务与分析”比简单增加一个存储副本复杂的地方。
PD 管理位置、调度与时间戳
数据会被切成 Region。PD 根据节点上报的信息了解数据的位置、容量和负载，并协调调度；SQL 层也需要知道目标数据所在的位置，才能发起访问。
事务还需要一致的时间次序。杜振强借此比较集中授时、专用硬件辅助与混合逻辑时钟等分布式系统思路，说明不同设计有各自的成本。这里并不是给所有数据库排优劣，而是解释为什么时间服务也会成为架构中的一部分。
他先从一个实际问题切入：集群里每台机器的本地时钟可能并不完全一致，事务却要判断先后、保证读写看到一致状态。PD 提供的时间戳服务是团队选择的一种组织方式；他还提到硬件辅助和混合逻辑时钟等路线，各有设备成本、额外等待或实现复杂度。PD 因而不只是“知道数据在哪”，还参与定义分布式事务所需的时间顺序。
Region 与副本机制，让数据调度进入数据库内部
一个 Region 会有多个副本，副本之间通过 Raft 协作；写入需要满足相应的复制条件，不能只看某一台机器已经收到请求。新增节点之后，系统可以逐步把部分 Region 调度过去，重新平衡数据分布。
他把一次写入拆成更具体的步骤：Region 的副本形成 Raft 组，写入先到 Leader，再复制到满足多数要求的节点，之后才向上层确认。若 Leader 随后故障，仍有已收到记录的副本可以参与恢复。Region 的位置和负载会上报给 PD；新机器加入时，PD 才有依据把部分 Region 逐步迁过去，而不是让应用重新计算每条订单该落在哪张表。
他接着介绍分布式事务与自动分片的关系：应用不必自己把一张逻辑表拆成许多物理表，再维护全部路由规则。TiKV 也可以被单独作为键值存储使用，但那是另一种使用接口，需要与通过 TiDB 使用关系数据库区分。
分库分表的成本，会随业务变化逐渐显现
当单机遇到瓶颈，分库分表是很多团队熟悉的办法。问题不只是第一次怎样拆分，还包括之后怎样再次扩容、怎样维护更多实例，以及业务是否必须知道分片规则。
杜振强举了订单数据的例子：如果按一种维度分片，换一个维度查询就可能变得困难。为了满足用户、商家等不同入口，团队可能维护额外的数据副本或索引体系；跨分片事务、关联查询与一致性又会增加实现难度。
比如先按订单号拆，按订单号查很直接；要查看一个用户的全部订单，或从商家角度统计交易，就可能需要跨许多分片访问。团队于是为用户维度、商家维度再各建一套数据，写入和维护成本也随之增加。原来四个库不够时再拆到八个、十六个，开发者还要配合更换路由与迁移。这个例子解释了为什么“能分片”与“让业务长期容易使用”是两件事。
高可用同样需要完整考虑。数据库、中间件、复制方式和外部切换工具共同构成系统，任何一层都可能引入维护工作。TiDB 的目标，是把分片、调度、事务等能力更多地放进数据库内部，减少业务为规模增长反复改造的负担。
这并不意味着扩展没有成本。录播中的节点数量与吞吐示例，是用来解释扩展方向；实际容量规划仍需同时考虑热点、SQL、网络、存储和故障条件。
HTAP 关注的是事务与分析怎样共同工作
行存与列存，服务不同查询
分享随后转向 TiFlash。按单条订单查询，与按日期、状态等条件进行大范围分析，适合的访问路径不同。SQL 优化器可以结合统计信息选择行存、列存或组合执行，分析计算还可以使用并行处理能力。
这里需要区分数据同步和读一致性：TiFlash 不是应用直接写入的第二套主库。官方 v6.5 文档说明，它以 Raft Learner 异步接收列式副本，在读取时检查复制进度，以满足快照读取的一致性。不能将分享中的“写完即可查”理解为复制完全没有等待。 · TiFlash v6.5 文档
减少链路，不等于所有分析需求都不再需要加工
传统做法可能需要把关系数据库中的变化通过同步、消息和加工系统送进分析存储，再将结果回流给业务。组件越多，越需要考虑链路可靠性、数据延迟、团队技能与维护成本。
杜振强把这条链路逐步讲出：线上关系库承接订单或用户动作，同步工具读取变化，消息系统传递，再进入列存或分析系统加工；若分析结果还要用于线上风控或推荐，就得把结果送回在线服务。每多一个环节，团队都要解决部署、故障恢复、数据是否及时到达以及谁能维护的问题。TiFlash 能减少其中一些为同一批数据搭建的链路，但跨来源清洗和复杂加工仍可能需要其他系统。
杜振强用实时风控、用户画像等场景说明 HTAP 的价值：让部分事务与分析工作在较统一的体系内完成，减少为同一批数据维护多条链路的负担。他强调的是这种整合机会，而不是说所有数据清洗、跨系统汇总和分析平台都会因此消失。
改表能力也影响业务交付速度
在线 DDL 是另一项重点。大表或大量分表修改结构时，迁移、增量同步、锁与复制延迟可能拖慢业务迭代。分享将 TiDB 的在线结构变更与这些运维工作作比较，同时指出增加索引仍需要处理已有数据，与只改变元数据的操作不同。
他以订单表改结构说明业务压力：若数据已经拆在许多库和表上，同一个字段或索引变更要逐一安排，线上流量还不能停。团队可能建立新表、搬运旧数据，再跟进新增写入，直至切换完成；节点和分片越多，窗口越难安排。TiDB 的在线 DDL 想把这类工作放进数据库能力里，但“加索引”必须扫过和组织已有记录，不能与只改少量元信息的操作混为一谈。录播中按十亿级记录估算的速度属于当时环境，不是对任意表的时限承诺。
他还谈到后续性能、稳定性、多租户与云服务方向。录播中的速度倍数和未来提升目标属于当时演示与计划，不应被写成所有表规模、所有版本都能达到的固定结果。
上云之后，继续拆开计算与存储
托管只是起点，底层架构还可以变化
在介绍 TiDB Cloud 时，杜振强区分了已有部署方式与当时处于推进中的新架构。把数据库放到云上，并不自动意味着已经充分利用云的资源特征；对象存储、弹性计算和按需使用，还会推动系统进一步改变。
他讨论将完整数据放入对象存储、在本地保存适合低延迟访问的数据副本或缓存。这样做的前提，是同时处理对象存储访问特点与事务访问要求，而不是简单把每次小请求都转成远程对象读取。
主持人若只听“数据下沉到对象存储”，很容易追问：事务查询岂不是每次都要远程取对象？杜振强自己先提出了这个疑问。他说对象存储在单次访问延迟和细碎请求上并不适合直接承接全部 OLTP 操作，所以新设计还要利用本地磁盘保存热数据或缓存。对象存储负责提供完整数据基础，本地层继续保障高频小请求的访问体验；两者分工之后，弹性收益才有机会成立。
弹性能力与数据搬迁方式有关
传统节点扩缩容时，数据往往要在已有节点之间搬迁，搬迁又会占用正在服务业务的资源。新的设计希望利用对象存储来恢复和加载数据，减少对已有节点的影响，让资源调整更快。
他还从 LSM Tree 的 compaction 谈到重复工作：如果每个副本都独立做相近的数据整理，会带来额外 CPU 和 I/O 成本。共享底层数据有机会减少其中一部分重复，并为不同副本组织方式提供空间。这些讨论是当时架构演进的说明，不意味着任意部署都能直接减少副本而保持相同可靠性。
这一步的推理是先看扩容路径：旧设计中，新节点需要从正在服务请求的节点搬来数据，搬迁速度又要限制，避免压垮现有负载；若完整数据位于对象存储，新节点可以从那里加载，并以本地数据承接低延迟访问。随后才有减少重复 compaction 和改善弹性的可能。杜振强提到的提升倍数及副本调整，是当时测试与后续设想，不能脱离具体架构当作通用承诺。
分析计算也需要应对高低峰
TiFlash 既存储数据，也执行分析计算。分享讨论进一步把这两部分拆开，使计算资源能够跟随分析任务的高低峰变化。例如某些报表集中在固定时段运行，资源没有必要全天按峰值配置。
这条路线最终指向更强弹性与按需付费。相关版本和上线时间在录播里属于当时计划，不能把后来发布的能力倒写成现场已经可用的产品。
场景选择，要同时看负载与资源门槛
分享归纳了三类需求。第一是规模较大、吞吐较高的事务业务，希望减少反复分库分表。第二是多个业务共同使用资源，通过适当隔离提高整体利用率。第三是同时存在事务和分析需求，希望缩短数据进入分析的链路。
小业务并不天然适合独立部署一个完整分布式集群。多个组件与副本都有资源成本，因此杜振强也讨论多个业务的整合，以及逻辑隔离和指定节点承载关键数据等不同方式。
他举出的整合思路是，把原本分散在许多小 MySQL 实例中的业务放到一个资源池，让高低峰不同的负载共享集群，再按重要性选择隔离程度。一般业务可利用逻辑隔离；若订单或支付等核心服务需要更强边界，则考虑把相关数据放到指定存储节点。这样既说明分布式系统的启动成本，也说明“多租户”不能只理解成把所有业务无差别混在一起。
最后，他以支付、内容平台、游戏、风控、广告与链上数据分析等历史场景说明可能的应用方向。案例的意义是观察负载结构，不是借客户名称替代选型验证。
AI 的第一步，是改善人与数据库之间的接口
技术分享演示了用自然语言生成 SQL 的 Chat2Query。用户描述想查什么，再检查生成的语句，确认后执行。杜振强期待它降低使用数据库的门槛，同时承认识别与生成质量仍需提升。
访谈把这个问题扩展到日常工作。他认为 AI 可以协助统一技术文档风格、改善表达和翻译，尤其适用于不同岗位共同维护材料，以及与海外团队沟通。主持人则分享准备英文演讲稿的经历：先交代场合、目的和必要信息，再把生成结果作为起稿材料。
杜振强举的例子是研发和产品经理分别写文档，语气、结构和术语不一定一致，用户读起来会不断切换。让工具按统一风格润色，可以先减少这种跳跃；给东南亚团队准备英文材料时，指定语言风格再翻译，也能省去逐句斟酌的时间。主持人接着谈自己作为管理者准备英语讲话：提供场合与中心意思，让工具生成初稿，再由自己判断是否合适。两人的共同前提是人先知道要表达什么。
两人还设想能够理解日程、会议目标和协作者时间的个人助手。这是对未来工作方式的想象，并不是说当时工具已经自动拥有公司日历或全部业务数据的访问能力。
代码与运维的辅助，仍要回到具体任务
关于编程、架构建议和数据库运维，两人讨论了 AI 对标准化工作的帮助，也举出生成代码留下待办事项的反例。它可能帮助组织思路，却不等于已经完成真实交付。
主持人强调，通用模型并不天然掌握企业的业务数据。杜振强倾向于把当时的工具当作助手，把机械性工作交给它，再由人承担判断；双方对未来能力会发展到哪里保留了不同程度的想象。关于岗位替代，他们谈的是推测，而非确定的结果。
转到数据库领域，需要理解自己要转向哪一种工作
观众问，Java 开发竞争激烈，是否可以转数据库开发。杜振强没有把语言当作唯一门槛：数据库内核涉及事务、存储、分布式理论和论文实现，还需要真实项目、指导与持续投入。
主持人将问题追问成“是不是不推荐 Java 开发者转行”，杜振强没有把它说成禁令。他指出数据库内核常用的语言和业务 Java 开发不同，但语言只是入口；对事务、存储和分布式原理的学习投入更大。有人带着进入团队、有机会在真实项目里练习，会比独自换一门语法更关键。他同时提醒，数据库领域也有大量竞争者，不能只因为原方向拥挤就认为换赛道必然更轻松。
他认为获得进入领域的机会和有人带领很重要，但不能因为原有方向竞争激烈，就假设另一个行业没有竞争。对已经积累业务经验的开发者，继续深挖一个行业，也可能形成自己的价值。访谈中的建议是提醒评估学习成本和兴趣，并不是宣称某种语言背景不能转行。
出海的数据库方案，需要把地域、沟通与账单一起考虑
杜振强介绍，团队在海外业务中经常使用云服务。这能减少自行建立机房和当地运维团队的负担，但方案仍要适应不同地区的实际条件，包括数据存放、跨地区同步、容灾与安全要求。
技术交流也需要重新解释概念。国内团队熟悉的简称，直接翻译后未必能让海外同事理解；理解对方的系统背景，比只把中文词换成英文更重要。
他的例子是“分库分表”：国内工程师一听便知道一系列拆分与路由做法，北美或东南亚同事未必使用这个总称。介绍方案时需要解释为何拆、怎样分片、应用要承担哪些路由规则，才有共同讨论的起点。出海因此不只是把产品文档翻译一遍，还要重新检查数据放置、跨地区同步、容灾和不同地区的安全要求。
他尤其提醒核对云服务的完整计费方式。机器配置只是其中一部分，网络传输、额外组件与不同操作的收费，都可能影响最终成本。录播中的账单落差是经验提醒，不是某家服务商的统一价格规则。
关于东南亚数据应放在哪里，现场表达较为概括。可保留的工程问题是：需要按具体国家、数据类型和业务安排核查存储与跨境条件，不能把整片区域当成一套法律，也不能据此认定所有跨境传输都违法。随后关于软件开发与网络安全的追问，两人又回到个人兴趣、投入方式和既有经验，没有给出一个对所有人都更好的职业答案。
原生分布式与中间件：谁来承担复杂度
访谈再次解释云原生与分布式的关系。杜振强关注存算分离、资源池化和弹性调整，认为分布式设计为这些目标提供了重要基础；这属于他对数据库演进路径的判断，不能仅靠一个名称认定产品已经具备全部云能力。
中间件分库分表与原生分布式数据库的共同点，是利用分片扩大承载能力。差异在于，业务需要知道多少底层规则：自己选择分片键、维护路由并限制查询，还是由数据库管理更多数据分布和事务细节。
他们比较了跨分片查询、复制一致性、结构变更与运维工具，也保留了资源起点的区别：单机较容易起步，分布式系统通常需要更多组件和机器。减少业务感知，并不意味着底层复杂度消失，而是把更多责任转交给数据库及其工具体系。
主持人接着问：既然应用少操心分片，学习和维护成本是否一定更低？杜振强把资源起点单独拎出来回答：一个小 MySQL 实例可以从单机开始，而分布式部署需要满足多组件、多副本的基础配置。对开发者来说，少写分片路由和迁移逻辑有价值；对小业务来说，先把多个负载整合到同一集群，也许比每个业务各开一个集群更合适。选型要同时算应用改造成本与基础资源成本。
开源社区和商业服务，可以服务不同需求
谈开源价值，杜振强首先提到新的思路、代码贡献和真实使用反馈。让不同团队在各自场景中尝试，能够更早发现问题，也帮助产品看见单个研发团队难以覆盖的需求。
社区本身仍需要投入。早期用户不熟悉系统，官方需要参与讨论、支持、培训和文档建设；随着经验积累，用户之间可以逐渐形成互助。开源并不是发布仓库之后，支持工作就自动完成。
商业化面向的另一类需求，是希望直接使用数据库服务、减少自行维护负担的团队。托管云服务和线下技术支持可以承担更多运行责任，用户购买的不只是代码访问，而是交付和持续服务。
主持人也指出，社区参与者能够通过阅读、贡献和协作获得成长；这些收益不要求每个人都成为商业客户。录播呈现的是开源产品、社区与服务之间的一种组合方式，而不是所有开源项目都适用的统一变现公式。
数据库竞争最终需要长期产品积累
最后，杜振强谈到与国际主流数据库竞争。他承认成熟厂商经过长期发展，具有深厚能力；新架构带来差异化机会，但不能替代稳定性、产品能力和真实使用场景的积累。
他也观察到，国内能够阅读内核和参与底层工作的开发者正在增加。人才、场景与持续投入，为产品发展创造条件；结果仍需要时间检验。两段分享由具体架构出发，最后回到相同的问题：技术选择怎样进入可持续的产品、团队和业务实践。