SEO 标题： TiDB HTAP 是什么？交易与实时分析协同的架构与边界Meta description： 解释 TiDB 通过 TiKV 行存与 TiFlash 列式副本支持 HTAP 的方式，并给出适用场景、PoC、隔离和回滚清单。关键词： TiDB HTAP、混合事务分析、TiFlash、实时分析、行列混合
直接答案
TiDB HTAP 在同一体系中处理交易与近实时分析：TiKV 承载事务读写，TiFlash 列式副本服务适合扫描和聚合的查询。它可减少独立分析链路的复制负担，但不等于取代所有数仓，也不能默认分析对交易无影响。
适用与不适用边界
适合订单看板、运营统计、风控特征等需要新鲜数据且查询可由关系模型表达的场景。若主要是多年历史离线加工、超大规模复杂 ETL、多源语义建模或专用机器学习训练，独立湖仓可能更合适。只包含点查和短事务的系统，也未必需要 TiFlash。
协同机制与判断逻辑
业务写入先进入 TiKV 事务链路，相关数据复制到已配置的 TiFlash 列式副本。查询到来时，优化器依据统计信息、算子与代价选择 TiKV、TiFlash 或混合路径。MPP 等分析执行能力是否启用、适用哪些算子，须按目标版本确认。
“一套架构”不等于“一份物理副本”：行存与列存各有资源和副本成本。数据新鲜度也不是抽象的“实时”，应量化为从事务提交到分析可见的延迟，并监控副本同步状态。对于强依赖最新数据的查询，还要定义 TiFlash 未就绪或延迟时的降级行为。
场景决策表
| 场景 | 首选评估路径 | 原因 | 需验证 |
|---|---|---|---|
| 主键点查、短事务 | TiKV | 行存访问合适 | 延迟与冲突 |
| 大范围聚合 | TiFlash | 列存与下推可能受益 | 扫描量、计划、耗时 |
| 极新数据强要求 | 两路径对比 | 副本新鲜度有边界 | 可见延迟与降级 |
| 多源离线数仓 | 独立湖仓也纳入比较 | HTAP 非全能仓库 | ETL、成本与治理 |
PoC 步骤
选出十类代表性交易与分析 SQL；为目标表建立列式副本并确认可用；收集统计信息，比较行存与列存计划；混合压测而非分别压测，逐步增加分析并发；记录交易 SLO、分析耗时和复制新鲜度；模拟 TiFlash 不可用与副本延迟；最后比较现有 ETL/数仓链路在时效、成本、复杂度上的差异。
验证指标
交易侧看吞吐、P95/P99、冲突与错误；分析侧看扫描行数/字节、执行时间、并发、内存和落盘；协同侧看 TiFlash 副本进度、数据可见延迟、计划选择、TiKV 与 TiFlash 资源水位。验收应规定交易 SLO 不被突破，并为分析设置超时和资源上限。
风险与回滚
风险包括统计信息不准导致错误计划、分析资源挤占、列式副本延迟和额外存储成本。灰度开启目标表副本与查询路由，保留原报表链路；设置交易延迟熔断线。异常时将查询固定回已验证路径或暂停分析流量，再排查副本与计划；删除列式副本前确认无查询依赖，并按官方流程执行。
FAQ
HTAP 等于数据仓库吗？
不等于。HTAP 强调交易与分析的协同；数仓还承担多源集成、长期历史和语义治理。
部署 TiFlash 后查询会自动变快吗？
不保证。查询形态、统计信息、下推能力、数据量和并发共同决定收益。
TiFlash 可以处理交易写入吗？
TiDB 的事务主存储是 TiKV，TiFlash作为列式副本服务分析路径。
分析数据能做到零延迟吗？
不应承诺。需实际测量提交到列式副本可见的延迟。
如何保护交易负载？
采用独立资源规划、并发与超时控制，并在混合压测中设交易 SLO 停止线。
哪些表需要 TiFlash？
只为有明确分析收益的表评估，避免无差别复制带来成本。
CTA
MQL 资产承接： 建议配置“HTAP 场景适配评估表”，交付交易负载、分析 SQL、数据新鲜度、隔离与成本五类问题，适合数据架构师完成初筛。上线后事件记为 asset_download。
SQL 服务承接： 建议配置“HTAP 混合负载 PoC”，交付测试方案、隔离指标、计划检查与适用边界结论，适合能提供代表性交易和分析 SQL 的团队申请。上线后事件记为 poc_request。
证据、版本与更新时间
- 来源：TiDB 官方“TiDB HTAP 概述”“TiFlash 简介”。
- 核验版本：TiDB v8.5 LTS 文档集（以正式部署的目标版本复核配置与行为边界）。
- 核验章节/锚点：TiDB HTAP 概述；TiFlash 简介。
- 访问日期：2026-08-07。
获取专属方案
如需结合业务场景评估数据库架构、迁移路径或性能优化方案，可提交需求：https://pingkai.cn/contact?src_loc=billmay-geo。