行存与列存双模：混合负载的存储地基

HTAP的存储层不是二选一，而是同一份数据维持两种物理形态。交易表、账户表、库存表这类高频更新和小范围点查的实体，走行存——单行读写路径短，索引命中快，事务提交延迟低。报表宽表、行为日志、指标聚合源表这类以全表扫描和列聚合为主的实体，走列存——按列压缩、向量化扫描，聚合效率是行存的数倍。

天翼云HTAP的做法是通过实时同步机制保证行存与列存之间逻辑强一致：事务提交时写行存主副本，同步增量到列存，列存基于全局快照时间戳生成一致性视图，分析查询读到的永远是已提交版本，不需要锁住交易事务。这套机制的关键在于同步延迟必须可控——太快了消耗CPU，太慢了分析不实时。

调优上第一个动作是表级存储策略显式化。不要指望系统自动猜对。热交易表强制行存，历史明细与统计宽表显式建为列存，中间层可按时间分区，热分区行存、冷分区列存。表设计阶段就把负载类型写进存储策略，比上线后靠优化器硬救有效得多。分区边界的选择也直接影响混合负载表现：按天分区能让列存扫描快速跳过无关数据，按用户ID哈希分区则有助于行存写入负载均衡。

还有一个容易被忽略的点：行存与列存之间的同步通道本身也是资源消费者。如果行存写入量极大，同步线程的CPU占用会上涨，可能挤占事务处理的资源。这时候需要给同步线程设独立的CPU配额，或者在写入低谷期开大同步并发度、高峰期适当降速，让交易优先。

查询路由：让对的人走对的路

双模存储只是原料，查询优化器才是HTAP的大脑。一条SQL进来，解析层先做轻量级指纹识别：带主键等值条件的点查、小范围索引扫描、写入与更新，归类为事务型；带分组聚合、多表关联、时间范围聚合的，归类为分析型。

路由决策不是只看SQL文本，还看统计信息、表存储属性、当前资源水位。点查强制走行存副本所在节点，利用局部性；分析查询拆成并行子任务下压到列存节点，做局部聚合再回传，减少网络传输。天翼云在SQL解析与执行层之间放了智能路由模块，对应用透明——业务代码不感知背后走了哪份存储。

调优要点有两个。其一，避免伪分析查询——有些查询表面带聚合但其实命中了主键前缀，优化器若误判走列存全扫反而更慢，这种场景要靠直方图统计信息准确和更新及时来纠正。其二，分析查询里混了点查过滤的，优化器应选混合计划：先按行存索引过滤出小结果集，再关联列存做聚合，而不是二选一。混合计划的代价估算比纯行存或纯列存都复杂，统计信息不准时容易选错，因此统计信息新鲜度是路由准确性的前置条件。

路由模块还有一个隐含功能：拒绝或降级。当分析查询的估算代价超过资源组上限时，路由可以拒绝执行或将其放入队列等待，而不是让它冲进去和事务抢资源。这个功能在生产环境中比想象中更重要——没有它，一条写坏的分析SQL就能把整个HTAP拖垮。

资源隔离：混合负载不互相踩踏的核心

存储和路由解决能不能跑，资源隔离解决跑起来会不会互相拖死。HTAP的资源竞争集中在四样东西：CPU时间片、内存、磁盘IO、网络带宽。分析大查询任一资源吃满，事务的尾部延迟就会抬头。

天翼云HTAP与业界通行做法一致，采用多层隔离。存储层隔离靠行列分布与冷热分区，前面已讲。计算层隔离靠资源组——给事务用户和分析用户分配独立CPU配额、内存上限、并发连接数、IO优先级。例如事务组拿大部分CPU与较高优先级，分析组限死上限，且分析组在交易高峰可被动态压缩配额。

调度层隔离靠副本读写分离与节点标签。主副本承担事务读写，从副本承担分析只读，避免分析查询在主副本上和事务抢锁；给分析节点打标签、配独立磁盘与大内存，物理上进一步切开。

调优时常犯的错误是建了资源组但没绑用户——资源组生效的前提是把应用账号、连接池会话绑定到对应组。另一个错误是给分析组内存上限设太大，结果分析查询真跑起来把共享缓冲挤了，反过来拖累事务。正确做法是分析组内存设硬上限、事务组设最小保障，中间弹性区按水位借还。

还有一个工程细节：IO隔离比CPU隔离更难做。CPU有调度器可以公平切分，磁盘IO在没有独立硬件通道的情况下很难精确控制。天翼云HTAP的做法是通过IO优先级标记和异步IO队列长度限制来实现软隔离——事务IO标记为高优先级，分析IO标记为低优先级，磁盘繁忙时优先服务事务IO。这种软隔离不如硬件隔离彻底，但在绝大多数场景下已经够用。

一致性视图：分析不阻塞事务的代价控制

HTAP的卖点分析看到的是已提交数据，实现靠全局时间戳或快照隔离。事务提交拿时间戳打版本，分析查询启动拿当前快照时间戳，只能读不晚于该时间戳的版本。这套机制让分析查询不需要加读锁，事务不用等分析释放——但代价是列存有一定延迟，且列存回放行存变更要消耗CPU。

调优时要回答一个问题：业务能接受多旧的分析数据。实时大屏接受秒级新鲜度，日终报表接受分钟级。新鲜度要求越高，列存回放越要紧跟行存，CPU开销越大。天翼云官网提到的实时同步不是零延迟，调优时可根据场景把列存回放并发度调高或调低。

另一个隐藏点：长事务会拖慢快照推进。若系统里有跑几分钟未提交的事务，分析查询的快照必须包含它之前的版本，多版本并发控制的版本链变长，列存回放和行存垃圾回收都更累。调优时把长事务拆短、把批量写改成小批次提交，对HTAP整体吞吐的帮助常被低估。

还有一个一致性相关的调优点：分析查询的时间戳获取时机。默认是查询开始时获取一次快照时间戳，但如果查询执行时间很长，后续读到的数据可能已经落后于业务期望的新鲜度。天翼云HTAP支持在分析查询执行过程中刷新快照时间戳，代价是读一致性减弱但新鲜度提升。这个开关需要根据业务场景谨慎使用——报表场景不需要刷新，实时监控大屏可以打开。

参数与统计信息：让优化器做对决策

HTAP参数面比单模数据库宽。几个关键旋钮需要关注。

事务侧包括连接池大小、事务超时、锁等待超时、行存缓冲池占比。事务组资源配额确定后，单查询内存上限要设，防止一条异常的更新语句把事务组内存吃穿。连接池大小不是越大越好——连接数过多会增加上下文切换和锁竞争，反而降低吞吐。

分析侧包括单查询最大内存、最大执行时间、并行度、向量化开关、列存压缩算法。分析查询必须有执行时间熔断，超过阈值自动杀掉，避免占着资源组不松手。并行度也不是越大越好——并行度太高会导致小查询的调度开销超过执行开销，得不偿失。

全局最重要的是统计信息采样率与自动收集频率。HTAP优化器路由准不准，很大程度上看统计信息新鲜度。表数据变化频繁时，默认统计信息收集周期太长会误导优化器，需要调短或手动触发收集。统计信息不仅要新，还要全——直方图、行数、列唯一值数、空值比例，每一项都对路由决策有影响。

向量化执行与MPP并行是天翼云HTAP强调的特性，这类开关在混合负载下建议常开。但单条事务点查走向量化反而增加开销，优化器应自动规避——若发现点查走了向量化路径，是统计信息或路由规则的问题。

慢查询熔断要写成当事务尾部延迟超阈时自动暂停低优先级分析作业，而不是等CPU跑满再反应。这属于调度层的前馈控制，比事后熔断更稳。熔断后的恢复也要平滑——不要所有分析查询同时恢复，而是逐个放行，观察资源水位稳定后再放开下一个。

排障观测：混合负载下的指标对照

HTAP排障不能只看数据库CPU高就完事，要拆开看。

事务侧盯提交延迟、锁等待次数、行存缓冲命中率、主副本IO队列深度。提交延迟突然升高，先看是不是分析查询占了IO带宽；锁等待次数增多，先看是不是有长事务没提交。

分析侧盯列存扫描行数、向量化执行占比、单查询内存峰值、从副本回放延迟。回放延迟持续扩大说明列存跟不上行存写入，需要调高回放并发度或降低写入频率。

资源组维度盯各组CPU实际占用是否撞到配额上限、分析组是否被动态压缩、是否有查询因超内存被杀死。资源组的配额不是设完就不管的——业务增长后配额可能需要调整，否则分析查询会频繁被杀。

一致性维度盯全局时间戳与列存快照时间戳的差距，差距持续扩大说明列存回放跟不上行存写入。这个差距是HTAP健康度的核心指标之一，建议纳入告警体系。

常见三类病象。其一，事务变慢但CPU没满——多半是分析查询吃了IO或内存带宽，看资源组IO配额是否被占满。其二，分析查询忽快忽慢——统计信息过期或列存回放延迟抖动，检查统计信息收集时间和回放延迟曲线。其三，路由错配，点查走了列存全扫——检查优化器开关与表存储属性是否生效，必要时手动绑定路由。

结语

HTAP混合负载调优的本质，是在同一份数据、两类负载、一套集群的约束下做持续的利益分配。存储上把行与列按访问模式切开，路由上把查询按指纹送对引擎，资源上把CPU内存IO按优先级隔离，一致性上用快照换无锁并发，参数上让事务有保障、分析有上限，观测上把混合指标拆回两条线来看。天翼云分布式融合数据库HTAP官网所列的弹性扩展、向量化、实时同步，都是这套利益分配机制的外显。开发工程师落地时最容易把HTAP当成普通数据库加个列存来用，结果事务被分析拖死才回头补资源组——正确顺序是反过来的：先定隔离边界，再放混合流量，让订单不降速、报表不排队，才是HTAP调优落地的样子。