批量 upsert（ON DUPLICATE KEY UPDATE）batch size 怎么定：锁等待、死锁与吞吐的权衡

【背景】 我负责一条实时指标落库链路：Kafka 消费端把聚合好的指标攒批后写入 MySQL 8.0.36（单主库，12C48G，InnoDB，redo 刷盘 innodb_flush_log_at_trx_commit=1，sync_binlog=1），写入语句是 INSERT ... ON DUPLICATE KEY UPDATE，主键是 (metric_id, ts) 组合，单条 60 字段。消费组 8 实例，峰值约 4000 batch/s（每 batch 100~500 行不等），目标是 P99 落库延迟 < 500ms 且不丢数据。

【现象】 把 batch size 从 100 提到 500 后，单 batch 平均耗时从 ~30ms 升到 ~140ms，整体吞吐没线性上去，反而出现两类问题：

1. 偶发死锁（错误 1213），集中在两个实例写相邻 metric_id 区间的窗口内，堆栈看是 gap lock + next-key lock 交叉；
2. 部分 batch 出现锁等待（information_schema.innodb_lock_waits 里能看到等待 200ms+），导致 P99 毛刺。 死锁重试后数据是对的，但重试把延迟进一步放大，且重试逻辑目前是「整批重放」，重放时已经 upsert 成功的行被再 update 一遍，造成不必要的写放大。

【已尝试的排查与结果】

• 确认是行级锁竞争而非全局锁：把 batch 降到 100、并对 metric_id 按 hash 分片到不同实例（每个实例只写自己的分片），死锁基本消失，但吞吐只到峰值 60%；
• 试过把 innodb_deadlock_detect 关掉改用超时（innodb_lock_wait_timeout=3s），死锁报错没了，但锁等待变长，P99 反而更差；
• 试过 SET unique_checks=0, foreign_key_checks=0 批量写入，单批耗时降了 ~15%，但没解决死锁根因，也不敢长期关。

【期望得到的答案形态】

1. 在「锁等待 / 死锁率 / 吞吐 / P99 延迟」四者之间，batch size 的经验区间和决策依据是什么？是按主键顺序、还是按并发实例数、还是按 innodb 页大小来定？
2. 对 upsert 死锁，「按主键区间分片到固定实例」是不是更稳的工程解？相比「关死锁检测 + 超时 + 整批重放」，各自的适用边界和风险是什么？
3. 幂等重放时，有没有比「整批重放」更细粒度的做法（比如只重放失败的行 / 用 RETURNING 或先查后写）来避免重复 update 写放大？
4. 是否值得为这条落库路径单独调 innodb 参数（如 innodb_buffer_pool、innodb_log_file_size、innodb_flush 策略），还是应该在上层做攒批 + 限流？ 欢迎给出你们线上的具体参数和数值，最好带可复现的配置。