PolarDB读写分离与列存节点路由优化实践

1. 问题背景与现象分析

最近在排查一个线上数据库性能问题时，遇到了一个很有意思的现象：原本运行正常的业务代码，在新增了一个写操作后，突然出现了慢查询。具体表现为：

java复制@Transactional(rollbackFor = Exception.class)
public void serviceMethod() {
    // 1.查询业务 - 正常
    select();
    
    // 2.新增的写操作
    insertOrUpdate();
    
    // 3.查询其他表业务 - 出现慢SQL
    selectAgain();
}

我们的数据库使用的是阿里云PolarDB，开启了读写分离功能，并且配置了列存节点。在业务代码2（写操作）上线前，代码1和3都能正常运行且没有慢查询；但在加入写操作后，代码3开始出现明显的性能下降。

2. 慢查询定位过程

2.1 问题SQL分析

出现问题的SQL语句如下：

sql复制SELECT * FROM table WHERE create_time < '2026-01-20' AND user_id = xxx LIMIT 1;

这个查询看起来很简单，但实际执行时却出现了性能问题。特别值得注意的是LIMIT 1这个条件，后面我们会发现它在这个问题中扮演了关键角色。

2.2 初步排查

通过EXPLAIN分析发现，这个SQL被路由到了列存节点上执行，测试环境中的查询时间约为30ms，但无法完全复现线上更严重的慢查询现象。

提示：测试环境与生产环境的数据量、负载情况可能存在差异，这解释了为什么无法完全复现线上问题。

2.3 紧急修复方案

基于经验，我们临时将查询修改为：

sql复制SELECT COUNT(*) FROM table WHERE create_time < '2026-01-20' AND user_id = xxx;

这种形式的查询会被强制路由到列存节点执行，暂时解决了性能问题。但这只是一个临时方案，我们需要深入理解背后的原因。

3. PolarDB路由机制深度解析

3.1 PolarDB架构概述

阿里云PolarDB采用了一写多读的架构，主要包含以下节点类型：

1. 主节点（读写节点）
2. 只读节点（从节点）
3. 列存节点（特殊的只读节点）

这种架构下，如何正确路由查询请求对性能至关重要。

3.2 事务中的路由行为

在我们的案例中，观察到了以下路由行为：

java复制@Transactional(rollbackFor = Exception.class)
public void serviceMethod() {
    // 1. 初始查询 - 正常路由
    select * from t_a where ...
    
    // 2. 写操作 - 必须路由到主库
    insert into t_b ...
    
    // 3. 后续查询 - 可能路由到主库或列存节点
    select t_c where .... limit 1
    
    // 4. 聚合查询 - 通常路由到列存节点
    select count(*) t_c where ....
}

3.3 事务拆分机制

PolarDB的"事务拆分"功能会将一个事务中的不同操作路由到不同节点：

1. 写操作（INSERT/UPDATE/DELETE）必须路由到主节点
2. 读操作通常路由到只读节点
3. 某些特定类型的查询（如聚合查询）会优先路由到列存节点

3.4 列存节点分流规则

列存节点特别适合处理分析型查询，但并非所有查询都适合。PolarDB会根据查询特征自动判断是否应该路由到列存节点：

1. 包含聚合函数（COUNT, SUM, AVG等）的查询
2. 涉及大量数据扫描的分析查询
3. 不包含LIMIT子句或LIMIT值较大的查询

在我们的案例中，LIMIT 1导致查询被认为是一个"点查"，不适合列存节点处理，因此路由决策出现了问题。

4. 问题根源与解决方案

4.1 根本原因分析

结合上述机制，我们可以总结问题根源：

1. 事务中先有写操作，导致后续所有读操作默认路由到主节点
2. LIMIT 1使优化器认为这是一个点查，不适合列存节点
3. 主节点可能负载较高，导致查询性能下降
4. 列存节点虽然适合分析查询，但不适合小结果集查询

4.2 完整解决方案

基于以上分析，我们制定了以下解决方案：

1. 强制路由提示：对于明确知道应该走列存节点的查询，使用HINT强制路由

sql复制/*+TDDL:cmd_extra(ENABLE_HLL=true)*/ 
SELECT * FROM table WHERE create_time < '2026-01-20' AND user_id = xxx LIMIT 1;

2. 查询重写：将不适合列存节点的查询改写为适合的形式

sql复制-- 改为聚合查询
SELECT COUNT(*) FROM table WHERE create_time < '2026-01-20' AND user_id = xxx;

-- 或者去掉LIMIT 1（如果业务允许）
SELECT * FROM table WHERE create_time < '2026-01-20' AND user_id = xxx;

3. 事务拆分调整：调整事务边界，避免写操作影响后续读操作的路由决策

java复制// 将写操作和读操作拆分到不同事务中
public void writeOperation() {
    // 写操作
    insertOrUpdate();
}

@Transactional(readOnly = true)
public void readOperation() {
    // 读操作
    selectAgain();
}

4. 监控与告警：建立完善的监控机制，及时发现类似的路由问题

5. 实践经验与注意事项

5.1 PolarDB使用最佳实践

1. 读写分离配置：

   • 简单查询走只读节点
   • 分析查询走列存节点
   • 写操作和事务中的读操作走主节点

2. 事务设计原则：

   • 尽量缩短事务持续时间
   • 避免在事务中混合读写操作
   • 对于只读操作，明确使用@Transactional(readOnly = true)

3. 查询优化建议：

   • 分析型查询避免使用LIMIT 1
   • 点查明确指定路由目标
   • 合理使用HINT指导优化器

5.2 常见问题排查指南

5.3 性能优化技巧

1. EXPLAIN是你的朋友：任何性能问题首先查看执行计划
2. 监控路由决策：定期检查查询路由情况，发现异常模式
3. 渐进式优化：先使用临时方案解决问题，再深入分析根本原因
4. 测试环境模拟：在测试环境模拟生产数据量，更准确复现问题

6. 深入理解PolarDB路由机制

6.1 路由决策流程图

PolarDB的路由决策过程可以简化为以下步骤：

1. 判断是否在事务中
2. 判断是否有写操作
3. 分析查询类型（点查/分析查询）
4. 检查HINT指令
5. 根据负载情况选择具体节点

6.2 列存节点适用场景

列存节点最适合以下场景：

1. 全表扫描的分析查询
2. 涉及大量数据的聚合计算
3. 需要处理宽表的查询
4. 数据仓库类型的操作

而不适合：

1. 高并发的点查
2. 需要低延迟的小结果集查询
3. 事务中的随机读写操作

6.3 事务隔离级别的影响

不同的隔离级别也会影响路由决策：

1. READ COMMITTED：更容易路由到只读节点
2. REPEATABLE READ：更倾向于主节点
3. SERIALIZABLE：必须走主节点

在实际应用中，需要根据业务需求选择合适的隔离级别。

7. 案例扩展与变体分析

7.1 类似案例1：JOIN查询性能问题

sql复制SELECT a.*, b.* 
FROM table_a a JOIN table_b b ON a.id = b.a_id
WHERE a.create_time > '2023-01-01'
LIMIT 100;

这种JOIN查询加LIMIT的组合也经常出现路由问题，解决方案类似：

1. 去掉LIMIT（如果业务允许）
2. 使用HINT强制路由
3. 重写为子查询形式

7.2 类似案例2：混合负载场景

有些业务需要在同一事务中执行分析和点查操作，这时可以考虑：

1. 使用多个数据源配置
2. 拆分业务逻辑
3. 使用中间结果缓存

7.3 类似案例3：批量操作性能问题

大批量的INSERT...SELECT操作也经常遇到路由问题，解决方案包括：

1. 明确指定主节点
2. 分批处理
3. 使用专门的ETL工具

在实际工作中，理解数据库的路由机制对于性能优化至关重要。PolarDB作为一款云原生数据库，提供了灵活的路由策略，但也需要开发者理解其工作原理才能充分发挥性能优势。