feat: merge-DML batching optimization for binlog apply

[dnovitski]

Related issue: #1378

• contributed code is using same conventions as original code
• script/cibuild returns with no formatting errors, build errors or unit test errors.

---

Summary

Port of #1378 (by @shaohk) rebased onto current master with API adaptation, correctness hardening, and comprehensive tests.

What it does

When --is-merge-dml-event is enabled, gh-ost batches binlog DML events instead of applying them one-by-one:

1. Batching — Collects up to --dml-batch-size events, then emits at most 3 SQL statements (one batched REPLACE for inserts/updates, one batched DELETE, one for key-changing updates)
2. Deduplication — Within a batch, only the last event per unique-key value survives (e.g., 5 UPDATEs to the same row → 1 REPLACE)
3. Range filtering — Events targeting rows beyond the current row-copy high-watermark are discarded (they'll be copied by row-copy anyway)

Changes from original PR

• Adapted to master's builder-pattern query API (NewDMLDeleteQueryBuilder etc.)
• Security: Strict formatNumericValue type-switch (rejects non-numeric types, prevents SQL injection via interpolated DELETE values)
• Correctness: INSERT+DELETE within same batch emits DELETE (not no-op) to protect against row-copy race
• Correctness: Merge auto-disabled when table has >1 unique key (REPLACE semantics unsafe with secondary unique indexes)
• Correctness: Fixed strings.Contains("int") matching "point" → exact base-type switch
• Correctness: Key-changing UPDATE saves/restores dmlEvent.DML to avoid mutation
• Tests: 35+ test cases covering dedup scenarios, batch query structure, range filtering, type detection, and numeric formatting edge cases

Benchmark Results

Setup: MySQL 8.0 (Docker), 100K-row table, 8 concurrent writer threads generating ~2900 events/s (60% UPDATE, 25% INSERT, 15% DELETE), --dml-batch-size=100.

Mode	Wall-clock	Events Applied	Events Ignored	Effective SQL Queries
Standard	2m58s	~411,000	0	~411,000
Merge	2m57s	~265,000	~128,000	~8,000

Wall-clock is identical because this workload is row-copy bound (backlog stays at 0–1/1000). The optimization delivers:

• 98% fewer SQL queries to MySQL (411K → 8K)
• 32% fewer events applied via dedup (redundant updates to same rows eliminated)
• 33% of events range-filtered (beyond row-copy watermark, would be copied anyway)

The wall-clock improvement manifests on large tables (millions of rows, hours-long migrations) where DML apply becomes the bottleneck and backlog grows. The query reduction directly translates to less lock contention, less binlog volume, and lower replication lag on the target.

Go-level microbenchmark (query count per 1000 events):

Metric	Standard	Merge	Reduction
SQL queries	1000	3	333×

Usage

gh-ost ... --is-merge-dml-event --dml-batch-size=100

Auto-disabled (with log warning) when:

• Table's unique key contains non-memory-comparable columns (TEXT, BLOB, JSON)
• Table's unique key has nullable columns (NULL breaks comparison/dedup semantics)
• Table has more than one unique key (REPLACE semantics conflict)

Credit

Based on the work by @shaohk in #1378. Co-authored-by trailer preserved in commit.