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