Flink CDC 做SQL Server → StarRocks 的全量 + 增量同步对源数据库的压力分析

Flink CDC 做 SQL Server → StarRocks 的全量 + 增量同步，对 SQL Server 一定会产生压力。
但压力大小取决于：

1. 表大小（千万级 / 亿级）
2. 是否高并发业务库
3. 是否全量快照阶段
4. CDC 增量日志读取速度
5. 是否加过滤条件
6. SQL Server 磁盘性能
7. 索引设计是否合理
8. SQL Server 版本（Standard / Enterprise）
9. Flink 并发度
10. StarRocks 写入速度是否跟得上

一、先说结论（最真实）

二、最主要的性能压力来源（按重要度排序）

① 磁盘 IO 压力（最大头）

这是最核心的。

SQL Server 数据都在：

• MDF（数据文件）
• NDF（辅助数据文件）
• LDF（事务日志）

Flink CDC 全量时会大量扫表：

SELECT * FROM big_table

这会导致：

顺序读取大量数据页

磁盘持续读取：

8KB 数据页 → Buffer Pool → 网络传输

如果表 500GB：

意味着 SQL Server 要疯狂读磁盘。

结果：

业务 SQL 原本也要读磁盘：

select top 100 ...

结果被 CDC 抢 IO，业务变慢。

举例：

服务器磁盘能力：

1000 IOPS

业务原本占：

400 IOPS

CDC 全量扫表占：

700 IOPS

系统就爆了：

总需求 1100 > 1000

出现：

• 查询变慢
• 锁等待
• CPU 上升
• 超时

为什么 IO 最大？

因为：

CPU 可以扩展

内存可以缓存

磁盘速度最难提升

尤其机械盘最明显。

三、CPU 压力

全量同步时 SQL Server 要执行查询：

SELECT col1,col2... FROM table

需要：

• SQL 解析
• 执行计划
• 行读取
• 类型转换
• 网络封包

如果多并发读取：

8 个并发 snapshot reader

CPU 会升高。

四、Buffer Pool 内存压力

SQL Server 会把读取的数据页放缓存。

CDC 扫全表时：

大量冷数据进入缓存

把业务热点数据挤掉。

导致业务 SQL 原本命中缓存：

99%

变成：

60%

然后业务查询也去磁盘读，雪崩开始。

五、事务日志压力（增量阶段核心）

CDC 增量不是扫表，而是读：

transaction log

SQL Server CDC 本质依赖：

sys.fn_cdc_get_all_changes_xxx

或者读取日志解析。

如果业务写入量大：

每秒 1 万 update

那么：

日志持续增长

LDF 文件暴涨

Log Reader Agent 持续解析日志

Flink 持续消费日志

会带来：

• 日志磁盘 IO
• CPU
• log truncate 延迟

六、网络带宽压力

全量阶段：

SQL Server → Flink

如果 1TB 数据同步：

网络持续跑满：

1Gbps / 10Gbps

会影响：

• 应用访问数据库
• 备份传输
• 远程连接

七、锁竞争压力（很多人忽略）

如果 snapshot 隔离级别没处理好：

SELECT * FROM big_table WITH (TABLOCK)

可能阻塞业务写入。

或者业务更新时，CDC 查询被阻塞。

八、tempdb 压力

如果开启：

snapshot isolation
read committed snapshot

SQL Server 会使用：

tempdb version store

CDC 大查询时 tempdb 压力很明显。

九、最危险的场景（生产常见）

场景1：白天做全量同步

5000 万表，上午 10 点开始同步。

结果：

• CPU 95%
• 磁盘 100%
• ERP 卡死

场景2：日志消费跟不上

StarRocks 写慢。

导致 Flink 积压：

CDC offset 不前进

SQL Server 日志不能清理：

LDF 盘满

数据库挂掉。

场景3：无主键大表

Flink snapshot 会：

select * from big_table order by ??

极慢。

十、如何降低 SQL Server 压力（实战）

方案1：全量放夜间

凌晨 1 点开始

方案2：限制并发

Flink 参数：

scan.incremental.snapshot.chunk.size=5000
parallelism=2

别开 16 并发。

方案3：分批同步

按时间：

where create_time >= '2024'

方案4：只同步必要字段

别：

select *

改：

id,name,status

方案5：给主键/时间字段建索引

否则全表扫描。

方案6：监控 SQL Server

重点看：

CPU
PAGEIOLATCH
WRITELOG
CXPACKET
tempdb
log reuse wait

十一、如果是 SQL Server → StarRocks，谁最耗资源？

在 SQL Server 侧：

全量阶段：磁盘 IO > CPU > 内存 > 网络
增量阶段：日志 IO > CPU > 网络

十二、真实经验值（大概）

十三、最优实践（推荐）

第一次：
夜间全量 + 开启增量

以后：
只跑增量

新表：
单独补历史数据

十四、如果你是生产库（非常关键）

如果是 ERP / MES / OA / 财务库：

强烈建议：

从库同步（只读副本）

别直接扫主库。

十五、总结一句话

Flink CDC 同步 SQL Server 到 StarRocks，真正压垮 SQL Server 的通常不是 CDC 增量，而是第一次全量快照的大规模磁盘 IO 和缓存挤占。