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

Flink CDC 做 SQL Server → StarRocks 的全量 + 增量同步，对 SQL Server 一定会产生压力 。

但压力大小取决于：

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

一、先说结论（最真实）

阶段	对 SQL Server 压力
全量同步（Snapshot）	高压力
增量同步（CDC 日志）	中低压力
全量+增量同时运行	最高压力

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

① 磁盘 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 > 网络

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

数据量	压力
100万	很小
1000万	中等
5000万	明显
1亿+	高
10亿+	专项方案

十三、最优实践（推荐）

复制代码

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

以后：
只跑增量

新表：
单独补历史数据

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

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

强烈建议：

复制代码

从库同步（只读副本）

别直接扫主库。

十五、总结一句话

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