在TiDB的乐观事务模型和悲观事务模型下，当模拟“银行转账”这类存在热点账户（比如某大型商户的收款账户）高频并发更新的场景时，其TPS（每秒事务处理量）和延迟（P99/P999延迟）通常会受到多大程度的影响？有没有什么具体的参数调优实践或业务侧的设计模式，可以有效缓解这种“单点写”的热点问题？

[TiDBer_DiE2Mh1s (干嘛)]

在TiDB的乐观事务模型和悲观事务模型下，当模拟“银行转账”这类存在热点账户（比如某大型商户的收款账户）高频并发更新的场景时，其TPS（每秒事务处理量）和延迟（P99/P999延迟）通常会受到多大程度的影响？有没有什么具体的参数调优实践或业务侧的设计模式，可以有效缓解这种“单点写”的热点问题？

[元神启动]

悲观事务更优，TPS可能下降50%以上，P999延迟显著升高。乐观事务在高冲突下会因频繁的重试和冲突检测导致性能急剧恶化。以下是针对单点写热点的具体调优和设计实践：

事务模型强制为悲观：TiDB 默认采用悲观锁，比乐观锁更适用于高冲突场景。
开启“内存悲观锁”：TiDB v6.0.0 及以上版本默认开启，该特性通过内存中加锁避免落盘，可将 TPS 提升约 30%。
打散热点数据：对于热点账户主表，如果必须频繁更新，考虑使用 SHARD_ROW_ID_BITS 将数据分散到多个 Region 上。
调整调度参数：临时调高 leader-schedule-limit 加速 PD 调度，虽不解决根本，但可临时缓解。