在 SQL Server 生产环境中，核心业务系统常年运行，进行数据同步时最让 DBA 担忧的是什么？一是避免影响主库性能，二是严格管控权限安全，三是确保已部署的 Always On 高可用架构充分发挥价值。这三大痛点几乎是每位数据库管理员首先考虑的问题。
CDC 的增量数据流转路径为：事务日志 → 捕获进程 → 变更表。同步任务在增量阶段仅需从 CDC 变更表中拉取数据。若已启用 Always On，完全可以将同步读取的负担转移到可读副本，主库专注于业务写入和 CDC 捕获；同步账户只需分配读取权限，从而将对核心库的性能影响降至最低。
SQL Server CDC 增量读取原理
关键要点：SQL Server CDC 增量读取的入口并非业务表本身，而是启用 CDC 后创建的 capture instance 及其对应的 CDC 变更表。
每个启用 CDC 的业务表都会关联一张 CDC 变更表，命名格式通常为 cdc.。当业务表发生 INSERT、UPDATE、DELETE 操作时，变更首先写入 SQL Server 事务日志，随后由 SQL Server Agent 的 CDC capture job 捕获，并写入相应的 CDC 变更表。
同步任务在消费增量数据时，主要访问 cdc 架构下的以下对象：cdc. 存储业务表的 DML 变更，是最核心的数据来源；cdc.change_tables 记录 capture instance、源表、起始 LSN 等信息，用于识别 CDC 表和可读范围；cdc.captured_columns、cdc.index_columns、cdc.ddl_history 等元数据则用于识别捕获列、索引列及 DDL 历史。
其中，_CT 表中的每条记录除业务字段外，还包含以下几类关键 CDC 字段：
__$start_lsn：变更所属事务的提交 LSN，是增量进度推进的主要依据。__$seqval：同一 LSN 下的操作序列号，用于区分多条变更的执行顺序。__$operation：操作类型，1 代表删除，2 代表插入，3 代表更新前镜像，4 代表更新后镜像。__$update_mask：标识 UPDATE 操作涉及的列。
因此，SQL Server CDC 增量读取的核心逻辑十分清晰：按照 __$start_lsn、__$seqval、__$operation 等字段的顺序，逐条处理 _CT 表中的变更记录，然后将 INSERT、DELETE、UPDATE 的前后镜像转换为下游系统可处理的变更事件。
Always On 备库 CDC 原理
在 Always On 环境中，CDC 捕获仍然由主副本负责。业务 DML 写入事务日志后，SQL Server Agent 的 capture job 从日志中捕获变更，并写入主副本的 CDC 变更表；cleanup job 则根据配置的保留策略定期清理历史变更。
这些 CDC 变更表和元数据通过 Always On 日志同步和 Redo 过程在可读副本上保持可见。CloudCanal 连接到可读副本后，可直接读取已同步过来的 cdc.、cdc.change_tables 等对象，实现增量数据消费。
因此，在 Always On 场景下，优化的核心并非改变 CDC 的捕获方式，而是将同步任务对 CDC 表的持续查询从主副本转移到可读副本。主副本继续处理业务写入和 CDC 捕获，可读副本专门为同步链路提供 CDC 读取——各司其职，分工明确。
静态 CDC 与最小权限运行
SQL Server CDC 初始化需要较高权限：数据库级 CDC 要求 sysadmin 服务器角色，表级 CDC 和 capture instance 创建则需 db_owner 角色。这些操作通常由 DBA 在主库端一次性完成。
所谓“静态 CDC”，是指 CDC 相关对象由 DBA 预先创建完毕，后续同步任务在运行阶段不再动态创建 capture instance，仅消费已准备好的 CDC 表和元数据。
在该模式下，DBA 可以提前按照固定命名格式（db_schema_table_cc_static）为订阅表创建 CDC capture instance。后续同步账户只需对业务 schema 和 cdc schema 拥有 SELECT 权限，即可持续消费 CDC 数据，无需任何写入或管理类权限。
这种权限模型特别适用于核心数据库。同步账户无需长期持有 sysadmin 或 db_owner 权限，日常运行阶段仅保留读取权限。对于权限审计严格的 SQL Server 生产库而言，这往往是方案能否成功落地的关键因素。
表级多位点推进
在 SQL Server CDC 中，每张表的 _CT 捕获表相互独立，不同表的变更进度天然存在差异。若仅维护一个全局 LSN，会导致同步任务重复消费相同数据。
多位点机制的核心在于按表独立维护进度。每张表的位点主要记录当前读取的 LSN 和 __$seqval，读取 CDC 变更表时再结合 __$operation 识别操作类型：
- LSN：日志序列号，用于定位事务边界
__$seqval：同一 LSN 内多条变更的序列值，用于区分同一事务内的操作顺序__$operation：操作类型（1=删除, 2=插入, 3=更新前, 4=更新后）
在多表订阅、任务暂停恢复、CDC 表积压等场景中，多位点机制更便于问题定位：哪张表读取到哪个位置、哪张表出现延迟，一目了然。
总结
在 SQL Server Always On 场景下，CDC 捕获仍由主副本执行，增量数据同步通过连接可读副本来读取 CDC 表。
这样做的好处显而易见：既能复用已有的高可用架构，降低同步读取对主库的影响，又能让运行账户保持最小权限。对于主库负载敏感、权限要求严格的核心 SQL Server 数据库而言，这是一种更适合长期稳定运行的 CDC 同步方案。
