TiDB vs 传统分库分表：HTAP架构真的必要吗？

谈到“TiDB vs 传统分库分表：HTAP架构真的必要吗？”，很多人第一反应是：只要业务能跑，谁管它底层怎么折腾？但真遇到日均十亿级写入、同时还要支撑实时报表的场景，体验过传统分库分表那种“拆了东墙补西墙”的痛，才会认真掂量HTAP到底是不是刚需。

传统分库分表失效的临界点

分库分表解决的是单机写瓶颈，但代价是拆散数据关系链。一个简单的跨分片聚合查询，比如统计全量用户昨日付费金额，背后可能要在几十个分片里分别跑SQL，再在应用层手动合并——代码量翻倍不说，中间结果集传输网络开销惊人。更致命的是，一旦业务要求强一致性分布式事务，分库分表方案基本缴械：两阶段提交性能惨不忍睹，XA协议在跨库场景下几乎不可用。我见过某金融团队为了在1024个分片里做跨节点转账，被迫引入TCC补偿，光故障自愈代码就写了六千行。

HTAP到底解决了什么

TiDB这类原生HTAP数据库，本质上是用计算存储分离架构把OLTP和OLAP从物理上打通，但逻辑上隔离。行存（TiKV）处理高频事务，列存（TiFlash）跑分析查询，两者通过Raft协议保持数据实时同步。这对业务最大的价值不是快，而是“没了中间商”：

• 不再需要ETL管道把数据从MySQL同步到ClickHouse或Hive，省掉一个数据复制延迟和一致性校验的噩梦。
• 分析查询不再依赖分库分表后的定时汇总表，可以直接对全量明细数据做实时计算。比如IoT场景下，过去每小时的设备温度平均值需要提前跑批写入汇总表，现在一条SQL下去，TiFlash在1秒内就能扫完十亿行。

不是所有业务都值得上HTAP

说实话，把HTAP吹成银弹是不负责的。如果你的业务场景明确是纯OLTP（比如秒杀系统，全是点查和简单事务），或者分析报表可以容忍分钟级延迟（用离线数仓T+1就能满足），那传统分库分表加一个OLAP引擎的“混搭”方案其实更省钱。TiDB的TiFlash副本会占用额外内存和存储，单机内存64G以下根本玩不转——我亲眼见过测试团队为了省钱只配了32G内存，结果列存副本一建，系统直接OOM。

什么时候非HTAP不可

一个很具体的判断标准：业务分析查询的响应时间要求必须小于5秒，并且查询模式不可预知。比如运营后台的交互式分析，运营人员随时可能拖拽维度看实时趋势，你没法提前建好所有可能的物化视图。这种情况下，传统分库分表+ES的组合往往在Join逻辑上跪得一塌糊涂，而HTAP天然支持任意维度的即时聚合。

说到底，HTAP不是概念游戏，而是对“数据一致性+实时性+灵活性”三要素的折中。选不选它，取决于你愿意为这三项付出多少运维成本。