先定義同步承諾，再討論技術
CDC 的真正問題不是「哪一種最快」，而是下游究竟需要什麼保證。資料倉儲可能容許數分鐘延遲，但不能漏掉刪除；CRM 整合可能更在意欄位映射與重試；即時風控則通常要求交易順序與低延遲。若這些條件沒有先寫清楚，團隊很容易選到功能強大的工具，卻在上線後才發現來源權限、資料保留或錯誤修復方式不符合現場限制。
評估時至少要回答：可接受的延遲是多少、是否必須捕捉實體刪除、同一筆資料的更新順序是否重要、來源資料庫能否開放日誌權限、應用程式能否修改，以及下游是否可以冪等寫入。還要定義中斷後從哪裡恢復、如何重建全量資料、如何驗證來源與目標一致。CDC 是持續運作的資料產品，不只是一次性的搬運程式。
日誌式 CDC：完整度高，但維運邊界也最清楚
日誌式 CDC 讀取資料庫的交易日誌，例如 binlog 或 WAL，因此通常能取得新增、更新與刪除，並保留交易提交的先後關係。它不必反覆掃描業務表，對高變更量、低延遲同步，以及需要精確追蹤刪除的情境特別合適。若目標是把核心交易資料持續送往資料平台、搜尋索引或另一個資料庫，日誌往往是優先評估的方案。
代價是它與資料庫引擎、版本、權限及日誌保留策略高度相關。初始快照與串流的交接必須避免缺口或重複；讀取位置應在目標端成功提交後才持久化；來源日誌不能在消費者落後時過早清除。資料表改名、欄位型別變更或主鍵調整，也可能讓連接器停止或產生無法相容的事件。正式上線前應實際演練版本升級、結構變更、網路中斷與日誌位置失效。
不要把「exactly once」當成唯一設計目標。跨資料庫、訊息系統與 API 的端到端流程通常仍可能重送。更可靠的做法是保存來源位置，為變更建立穩定識別，並讓目標寫入具備可重放與冪等能力。這樣即使連接器重新啟動，也能安全地從已知位置恢復。
時間戳輪詢與事件模式：簡單不等於不用設計
時間戳輪詢最容易導入，通常只需查詢 updated_at 大於上次游標的資料，適合無法取得日誌權限、資料量適中、延遲要求較寬鬆的整合。但單一時間戳不是可靠游標：多筆資料可能具有相同時間、應用程式可能使用不同時區或時鐘，而且長交易的提交時間不一定等於欄位更新時間。實作上應使用「時間戳加主鍵」的複合游標、保留重疊查詢區間，並在目標端去重。硬刪除無法被一般輪詢發現，因此需要軟刪除欄位、刪除紀錄表，或定期全量對帳。
事件模式則由應用程式主動發布具業務意義的事件，例如訂單已核准或客戶資料已合併。它適合跨服務流程，卻不應被誤認為資料表的完整鏡像。若資料庫已提交但事件發布失敗，下游就會永久缺漏；較穩健的做法是使用 transactional outbox，讓業務資料與待發布事件在同一筆交易內寫入，再由發布程序送往訊息系統。事件需包含穩定的 event ID、實體識別、版本或順序資訊及 schema 版本，消費者仍要處理重複、延遲與亂序。
- 選日誌式：需要低延遲、捕捉硬刪除、維持交易順序，且能管理資料庫權限與日誌保留。
- 選時間戳式：來源限制多、同步規模可控、延遲要求較寬鬆，且能接受額外的刪除與對帳機制。
- 選事件式：下游需要業務語意而非資料列複本，並且應用團隊可以承擔 outbox、事件版本與消費者契約。
- 避免只看吞吐量：先比較故障復原、結構變更、重播範圍與日常監控的成本。
多數企業架構需要組合，而不是單選
實務上常見的答案是混合使用：核心資料庫透過日誌式 CDC 進入資料平台；舊 ERP 以時間戳輪詢同步主檔，搭配每日對帳；跨系統流程則使用 outbox 事件傳遞業務狀態。關鍵是不要讓三種管線互相覆寫卻沒有清楚的資料所有權。每個欄位或資料實體應指定權威來源，並定義衝突時採用來源優先、版本優先，或人工處理。
上線清單至少應涵蓋游標或日誌位置持久化、冪等鍵、死信處理、schema 相容性、來源與目標筆數或雜湊對帳，以及延遲與停滯告警。還要準備可操作的重播程序：先界定重播區間，再暫停衝突寫入，最後驗證結果。真正合適的 CDC 方案，不是正常運作時最漂亮的架構，而是發生斷線、重複、結構變更與人為錯誤後，團隊仍能解釋並安全修復的架構。