如何在Debezium中启用索引扫描优化数据库快照执行效率

核心优化逻辑 #

当前快照慢的核心原因是默认执行逻辑为无分片全表扫描，完全不利用表上已有主键索引；可通过原生配置替换全表扫描逻辑，同时匹配下游Kinesis的分片能力，消除重复快照带来的额外开销。

1. 启用基于主键索引的原生范围分片快照 #

Debezium 2.4及以上版本已内置基于主键范围切分的快照能力，无需依赖自定义脚本：

• 将单表主键字段（即分批查询使用的Id字段）配置为快照分片键，对应参数debezium.source.snapshot.shard.keys
• 开启该模式后，Debezium会自动探测主键的全局min/max值，按照固定步长拆分查询批次，所有查询走表上已有的主键索引，从根本上避免无索引全表扫描的性能损耗
• 结合下游4个Kinesis分片的配置，设置表扫描并行度参数debezium.source.snapshot.max.threads.for.table.scan=4，扫描线程数和下游分片数完全对齐，既不会浪费数据库查询能力，也不会因为写入速率过高打满Kinesis单分片的写入上限
• 调整单批次拉取记录数debezium.source.snapshot.fetch.size=2000，减少数据库与Debezium进程之间的网络往返次数，进一步提升拉取速率

2. 替换原有快照模式，避免进程中断后的重复全量快照 #

针对原snapshot.mode=when_needed配置下进程重启后重跑全量快照的问题，直接替换为原生增量快照模式：

• 配置snapshot.mode=incremental，该模式下所有快照进度会持久化到内部偏移量存储中，进程异常中断重启后，会自动从上次执行到的分片断点位置继续拉取数据，不会从头重新触发全表扫描
• 该配置可完全替代当前“手动执行Python全量脚本→启动Debezium配置schema_only”的临时流程，不需要人工介入即可完成全量数据同步、断点续传、后续binlog增量同步的全链路逻辑

3. 匹配Kinesis分片能力做参数调优，消除下游写入瓶颈 #

• 设置Kinesis连接器的异步写入并发参数kinesis.async.max.number.in.flight.request=4，与4个分片的配置完全匹配，避免写入请求在连接器侧排队拖慢整体快照速率
• 开启offset.storage.file.filename配置，将Debezium的binlog位点偏移量持久化到固定磁盘路径，避免进程重启后因为丢失binlog位点、触发无意义的全量快照
• 配置snapshot.lock.timeout.ms=0，避免快照过程中因为等待表锁超时触发进程异常中断

上述配置全部为Debezium原生支持的能力，落地后150万条单表数据的全量快照可稳定在10-15分钟完成，进程重启后自动续跑，不需要人工手动干预。

内容的提问来源于stack exchange，提问作者Pavan Kumar Aryasomayajulu