过去几年，企业对数据库的需求分化越来越明显。
一类场景需要数据库足够轻量、部署简单、成本可控—中小型业务、SaaS 被集成、行业垂直应用，追求"开箱即用、一台服务器就能跑起来"；另一类场景持续追求更强的分布式能力、更完整的生态、更稳定的企业级保障—金融核心、政企关键系统、大体量交易分析一体化业务，追求"扩得动、扛得住、查得快"。
与此同时，传统数据库架构在扩展性、兼容性、运维复杂度、数据管理效率上的短板越来越突出。再叠加 MySQL 8.0 今年 4 月已正式停止更新，自主可控从可选项变成了硬约束—"用什么数据库"不再只是一道技术题，而是一道关乎成本、合规、长期演进的综合题。
腾讯云 TDSQL 团队给出了解法：同一套金融级内核，按业务真实需求拆成三档版本。
很多人把"中小型业务"和"中小型企业"混为一谈，但这两者有本质区别。大型企业里真正容易被忽视的，恰恰是散落在核心系统之外的中小型业务：内部审批、轻量 SaaS、行业垂直应用。它们单个体量不大，但加在一起数量可观。
这类业务的选型一直比较棘手：硬件资源贵、运维人手不足；MySQL 8.0 省钱但停止更新后无人兜底；换商业数据库又要面对语法差异和改造成本；SaaS 厂商想进教育、政务等行业市场，没有合规资质连门都进不去。
TDSQL 基础版专为这类场景而生—腾讯自研、单机部署、完全兼容 MySQL 语法、自带白屏化运维平台。核心在于，资源冗余对中小型业务反而是负担：运维平台和数据库实例打包部署在同一台机器上，监控告警可选装，最低 1C2G 即可运行，容器化部署、一条 install 命令、约 10 分钟完成交付。底层内核与企业版同源，已为 4000+ 客户提供稳定服务，资质首批通过安可与政府采购标准。
简而言之，让中小型业务也能用上金融级内核，但不必为高可用额外付费。
业务体量再大、场景再复杂，TDSQL 企业版接棒—计算、存储、元数据、管控全栈自研，金融级高可用、计算存储分离、HTAP 一次给齐。MySQL/PG 全覆盖，特定场景下 Oracle 兼容性可达 98%。
杨磊在分享里反复强调一个词—"统一"。MySQL、PG、Libra、DBBrain 共用一份介质和白屏部署工具按需选装；实例、集群、监控告警一套界面纳管多引擎；License、API、角色管理标准化输出，客户系统对接一次适配、所有引擎通用。多引擎不再是多套独立产品。
企业版 HTAP 对原 TDSQL 架构零入侵。在原有管控、Proxy、DB 之外，把 Libra AP 引擎作为可插拔模块叠加上去，已经在跑业务的实例随时开启 HTAP 不用迁移，业务代码完全不动，访问统一走 Proxy 进行路由。落到场景上很具体：金融跑批的复杂事务变更、监管报送的多维实时校验、实时数据看板、ERP 类多源汇聚分析。加速对象还能精确到表级——个库 8 张表只给其中 4 张开 HTAP，一条语法就能控制。该重的地方重、该轻的地方轻。
企业版另一项升级是把 DBbrain 完整融入 TDSQL：7×24 实时监控加全方位诊断、按天按周自动跑的智能巡检与健康报告、基于审计日志的全链路可观测分析—运维不再依赖 DBA 自身经验，平台先一步把异常和风险摆上台面。
最近一年几项硬演进也值得拎出来。异构多芯让主实例非信创、灾备实例信创成为可能，DCN 跨架构实时同步、一键切主备，信创替换无需停机；黑匣子容灾通过同城稳定网络区放一份强同步日志副本，故障时把数据补到异地，第一次让异地 RPO=0 真正落地。性能上 NUMA 绑核让信创服务器就近访问内存最高提升 176%，PGO 编译优化再提升约 18%—一通调优之后，鲲鹏、海光、TencentOS 等国产环境的整体性能与英特尔 + Linux 完全持平甚至反超。安全上实现完整的密评能力，密钥管理与加密模块均已拿到商密局二级资质。当前主推 LTS 版本 22.1 / 22.6 / 22.8，创新版 22.9 已支持参数模板、秒级闪回、指定 set 回档等新能力。
如果说前两部分讲"产品线分层"，这部分讲的是 TDSQL MySQL 计算引擎的代际升级。
老架构存在几个明显短板：基于较老的 MySQL 版本、不支持 8.0 的主流能力（CTE、窗口函数、存储过程、触发器）、Oracle 兼容改造成本高、Reactor 模型多连接互扰、缺分布式优化器。所以新引擎不是修补，而是用协程框架重写：大量协程映射到少量系统线程，避免线程级开销，实现真正的高并发、低延迟、稳定执行。
执行路径分层判断、按需走最优路：简单 SQL 由 Fast Query Shipping 直接下推到 TDSQL 节点，性能对齐原 Proxy；复杂 SQL 进 Parallel Query MPP 框架并发执行；大数据量分析路由到 Libra 列存引擎，与 TP 资源彻底隔离。优化器同步增强 JoinElim、子查询消除、基于代价的分布式改造，跨分片聚合多维统计信息—选执行计划这件事，不再靠经验、而是靠代价。
新引擎同时支持分区表和分库分表两种维度，底层物理拓扑和 DDL 路由由计算引擎统一屏蔽。真正的杀手锏是三层全局索引：分区内索引保留 MySQL 原生用法；Set 内全局索引支持单分片内跨分区、无需影子表、使用成本最低；跨 Set 全局索引基于隐式影子表，提供全实例维度的唯一性约束、DML 自动维护、查询自动回表。不管分片键是不是查询条件，都能快速定位数据，跨分片扫描和广播查询大幅减少。
DDL 是分布式数据库的"高危动作"。新引擎给到三种模式：Physical DDL 直接下推适合简单变更；两阶段 DDL 让每个分片先 prepare 再统一 commit，保多 Set 原子性；最值得讲的是 Logical OSC—基于 binlog 的在线表结构变更，搭配影子表加增量回放，对应用写入零干扰，任一步出错都能无损回滚。整个 DDL 任务拆成 DAG 并行推进，状态落到 metadb，宕机可恢复。
Oracle 兼容也补到了存量用户能低成本迁移的程度—全局临时表、CONNECT BY、ROW_NUMBER、PL/SQL 等语法全部支持。叠加 HTAP 列存引擎，高并发 TP 与复杂 AP 第一次能在同一个实例里跑起来。
TDSQL 的"分层进化"，回答的其实是一个朴素的问题：数据库不该让客户为不需要的能力买单。中小型业务挑基础版，企业级核心场景走企业版，复杂查询和大规模分布式靠全新计算引擎—同一个内核、三档形态，从"被集成的轻量场景"覆盖到"金融核心系统"。
在 MySQL 8.0 EOL 这个分水岭上，这是一份足够稳的迁移答案，也是面向下一个十年企业数据库选型的一份系统化思路。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。