MySQL Sink: Recommendations for business which changes only a few rows very frequently

Before asking a question, make sure you have

• Googled your question
• Searched open and closed - TiFlow GitHub issues - TiCDC Github issues
• Read the TiCDC documentation

What is your question?

Our customer has a table with many (~30) columns. On upstream it executed UPDATE tbl SET last_updated = now() WHERE pk = 1234; very frequently with a very small set of pk. So the effect is

1. event size amplification, although upstream only modified one row, downstream will need to update all 30 columns (not a very big deal), and
2. non-scalable, because all UPDATE will inherently conflict with each other, these statements can never be executed in parallel and the effective worker-count is bounded by the size of the pk set (the main problem).

The questions:

• Should TiCDC care about optimization of this scenario? Or we just have to accept this has to be slow?
• If we care, any recommended configuration to tune for downstream performance?

Start with the TiCDC documentation linked in the issue and the MySQL sink behavior for frequent updates to a small primary-key set. Investigate whether existing downstream performance or worker-configuration guidance addresses this pattern, then document the recommended configuration or confirm that optimization would require a new design.