热点更新增强：合并优化

Download

聚焦模式

字号

最后更新时间： 2026-07-09 17:56:15

功能简介
云数据库 MySQL（TXSQL）的热点更新增强功能：合并优化，是针对高并发热点行更新场景的专项性能优化。在电商秒杀、金融账户入账等业务场景中，大量并发事务频繁更新同一行记录，传统的行锁机制会导致严重的锁等待排队，TPS 极低、延迟极高。
热点更新增强功能：合并优化，是在“热点更新：排队机制” 的基础上，引入了事务合并（Group Commit）的思想：将并发到来的热点更新事务自动组织成一个 group，group 内 leader 负责加锁，其余 follower 无需等待锁释放即可执行热点更新，事务内的其他语句可与其他事务并发执行。这一机制大幅提升了热点行更新的并行度，在半同步复制、高网络延迟等高事务延迟场景中效果尤为显著。
适用场景
电商秒杀：大量并发请求对同一商品库存行进行扣减。
金融账户入账：高并发资金流水对账户余额行进行更新。
积分/计数器：对同一计数行进行频繁累加操作。
库存管理：多仓库系统中对热门商品的库存行进行并发更新。
说明：
热点更新增强功能：合并优化，适用于事务延迟较高的配置，例如开启了半同步复制，或客户端与数据库节点之间存在较高网络延迟的场景。
功能原理
“热点更新：排队机制”方案的局限性
“热点更新：排队机制”采用的是排队串行的思路：事务在加锁前判断是否为热点行，若是则进入等待队列，前一个事务提交后才唤醒下一个事务。这一机制在低延迟场景下有一定效果，但在半同步复制或高延迟场景下，由于每个事务的执行时间较长，串行等待带来的吞吐量提升有限。
热点更新增强方案：事务合并（Group Commit）
热点更新增强方案的核心思想是利用 group 将一组事务进行逻辑合并，从而提高并行度。
并发事务 ──▶ Group 1 ──▶ Group 2 ──▶ Group 3 ──▶ ...
              │                │
           Leader            Leader
           Follower×N        Follower×N
关键机制
角色
行为
leader
负责对热点行加锁和解锁，事务结束时释放锁并唤醒下一个 leader。
follower
无需等待锁释放，在 leader 完成热点行更新后即可执行，事务内其他语句与其他事务并发执行。
执行流程
1. 并发到来的热点更新事务自动组成一个 group，第一个进入的事务成为 leader，其余为 follower。
2. leader 加锁并执行热点行更新。
3. leader 完成热点行更新后，立即 grant 下一个 follower 执行，无需等待 leader 提交。
4. follower 被唤醒后，重新读取当前最新数据，直接执行热点行更新（跳过加锁步骤）。
5. leader 在事务结束时释放行锁，唤醒下一个 leader，新的 group 随之形成。
由于 group 内的 follower 不再等待 leader 提交，事务等待锁的时间大幅缩短，在高延迟场景中提升效果尤为显著。
正确性保证
为保证合并优化在打破传统 2PL 约束后的正确性，云数据库 MySQL（TXSQL）实现了以下几项保证机制：
1. 提交序保证
group 内所有事务必须按照热点行更新的顺序依次提交，以保证 MVCC（多版本并发控制） 数据可见性和数据正确性。
在实现上，系统为每个热点更新事务分配全局递增的顺序标识，并通过机制确保事务严格按照该顺序进入提交队列，从而保证提交有序。
2. 回滚序保证
若 group 内某个事务需要回滚，则其后续所有已执行的事务都必须逆序回滚。
Server 层：通过信号机制通知所有等待提交的事务回滚。
InnoDB 层：通过维护热点更新事务依赖列表，确保只有列表末尾的事务才能回滚，其他事务等待前序事务回滚完成。
3. Crash Recovery
事务顺序信息会持久化到 undo log 中。数据库重启后，可从 undo log 中恢复未提交事务的顺序信息，按顺序逆序回滚所有未提交的热点更新事务，保证数据一致性。
性能提升效果
以下测试在半同步复制模式下进行，模拟热点更新入账业务（单热点行，sysbench 测试）。
说明：
触发热点更新合并优化的并发阈值设置为30，可通过 innodb_hot_update_threshold 参数进行设置。
TPS 对比
﻿
并发线程数
关闭热点更新
开启热点更新
加速比
8
671.15
668.64
1.0×
32
660.69
6,927.31
10.5×
128
635.14
15,304.53
24.1×
512
594.28
13,709.24
23.1×
1024
551.57
12,936.15
23.5×
95th Percentile 延迟（ms）对比
﻿
并发线程数
关闭热点更新
开启热点更新
延迟降低
8
12.08
12.08
1.0×
32
49.21
5.18
9.5×
128
204.11
9.56
21.4×
512
877.61
37.56
23.4×
1024
1903.57
77.19
24.7×
通过上面的测试结果对比，可以看出，在128并发线程下，TPS 提升约24倍，P95 延迟降低约21倍。并发越高，优化效果越显著。
参数说明
参数名
默认值
说明
innodb_hot_update_detect
OFF
是否开启热点更新探测。开启后，系统自动识别热点行并触发合并优化。
innodb_hot_update_threshold
30
触发热点更新合并优化的并发阈值。当对同一行的并发更新数超过该阈值时，触发热点更新机制。
参数调整建议
innodb_hot_update_threshold：若业务热点并发较低，可适当降低此阈值，更早触发热点优化。
使用限制
使用热点更新功能时，请注意以下限制。违反限制时，相关事务会报错并回滚。
限制项
说明
仅支持主键索引单条更新
SELECT FOR UPDATE 和 UPDATE 均须基于主键索引单条操作，且更新条件必须一致。若 SELECT FOR UPDATE 在二级索引上加锁，热点优化不生效。
SELECT FOR UPDATE 必须在 UPDATE 之前
若事务中同时包含 SELECT FOR UPDATE 和 UPDATE 热点行，SELECT FOR UPDATE 必须先执行。UPDATE 到来时，若已排过队则跳过排队直接执行。
一个事务中不允许对同一热点行多次 UPDATE
第一次 UPDATE 完成后，锁已释放给下一个事务，若再次 UPDATE 同一行，提交顺序会错乱，系统将报错并回滚整个事务。
热点行 UPDATE 后不允许有冲突 SQL
事务更新热点行之后，后续语句不能与其他热点更新事务产生锁冲突，否则报错并回滚整个事务。
热点更新期间不允许删除热点记录
若有 DELETE 请求操作正在被热点更新的记录，将报错并回滚整个事务。
热点更新期间不允许通过二级索引更新热点记录
若通过二级索引更新正在被热点更新的记录，将报错并回滚整个事务。
暂不支持线程池模式
在开启线程池（Thread Pool）的实例上，热点更新功能暂不可用。
使用方式
开启热点更新
热点更新功能默认关闭，设置参数 binlog_order_commits = ON 即可开启功能，开启后可自动识别热点行并触发合并优化。
您可以通过以下 SQL 查看当前参数状态：
SHOW VARIABLES LIKE 'innodb_hot_update%';
典型业务 SQL 示例
场景一：直接 UPDATE 热点行（最简场景）
BEGIN;
UPDATE account SET balance = balance - 100 WHERE id = 1;  -- 热点行，基于主键单条更新
-- 其他非冲突业务逻辑...
COMMIT;
场景二：先 SELECT FOR UPDATE 再 UPDATE（记录操作历史）
BEGIN;
SELECT * FROM account WHERE id = 1 FOR UPDATE;   -- 基于主键，进入热点等待队列
INSERT INTO account_log (account_id, amount, op_time) VALUES (1, -100, NOW());  -- 记录操作日志
UPDATE account SET balance = balance - 100 WHERE id = 1;  -- 热点行 UPDATE，触发 grant 下一个 follower
COMMIT;
注意：
SELECT FOR UPDATE 和 UPDATE 的 WHERE 条件必须一致，均须基于主键单条操作。
验证热点更新是否生效
可通过 select * from information_schema.INNODB_HOT_ROW_UPDATE_STATS 命令，或监控指标观察热点行相关统计信息，或通过 TPS/延迟指标的显著提升来确认功能生效。
注意事项
死锁场景：若事务在更新热点行之后，又与其他事务产生非热点行的锁冲突（即两个事务均更新了同一热点行，又对同一非热点行加锁），当前版本不支持自动检测并处理此类死锁，需要用户主动 KILL 相关事务。
备机回放：开启热点更新后，云数据库 MySQL（TXSQL）已针对此场景做了专门优化，避免备机并行回放时产生大量锁等待，防止主备延迟过高。
TPS 固定访问模型下的延迟：在 TPS 限速场景中，等待队列可能出现空队列，导致事务无法被唤醒。云数据库 MySQL（TXSQL）通过“新来事务主动加锁、开启新 group”的机制优化了此问题，但如遇延迟偏高，可适当调整 innodb_hot_update_wakeup_timeout 参数。
多热点行场景：当前版本多个热点行之间共享同一套顺序控制结构。在极端情况下，一个热点行上的事务回滚可能影响其他热点行上的事务也被回滚，此为已知限制，后续版本将进行优化。
支持版本
内核版本 MySQL 5.7 20250330 及以上。
内核版本 MySQL 8.0 20231130 及以上。
相关文档
﻿热点更新：排队机制﻿
﻿设置实例参数﻿

帮助和支持

本页内容是否解决了您的问题？

您也可以联系销售或提交工单以寻求帮助。

填写满意度调查问卷，共创更好文档体验。

文档反馈

角色	行为
`leader`	负责对热点行加锁和解锁，事务结束时释放锁并唤醒下一个 `leader`。
`follower`	无需等待锁释放，在 `leader` 完成热点行更新后即可执行，事务内其他语句与其他事务并发执行。

并发线程数	关闭热点更新	开启热点更新	加速比
8	671.15	668.64	1.0×
32	660.69	6,927.31	10.5×
128	635.14	15,304.53	24.1×
512	594.28	13,709.24	23.1×
1024	551.57	12,936.15	23.5×

参数名	默认值	说明
innodb_hot_update_detect	OFF	是否开启热点更新探测。开启后，系统自动识别热点行并触发合并优化。
innodb_hot_update_threshold	30	触发热点更新合并优化的并发阈值。当对同一行的并发更新数超过该阈值时，触发热点更新机制。

限制项	说明
仅支持主键索引单条更新	`SELECT FOR UPDATE` 和 `UPDATE` 均须基于主键索引单条操作，且更新条件必须一致。若 `SELECT FOR UPDATE` 在二级索引上加锁，热点优化不生效。
`SELECT FOR UPDATE` 必须在 `UPDATE` 之前	若事务中同时包含 `SELECT FOR UPDATE` 和 `UPDATE` 热点行，`SELECT FOR UPDATE` 必须先执行。`UPDATE` 到来时，若已排过队则跳过排队直接执行。
一个事务中不允许对同一热点行多次 `UPDATE`	第一次 `UPDATE` 完成后，锁已释放给下一个事务，若再次 `UPDATE` 同一行，提交顺序会错乱，系统将报错并回滚整个事务。
热点行 `UPDATE` 后不允许有冲突 SQL	事务更新热点行之后，后续语句不能与其他热点更新事务产生锁冲突，否则报错并回滚整个事务。
热点更新期间不允许删除热点记录	若有 `DELETE` 请求操作正在被热点更新的记录，将报错并回滚整个事务。
热点更新期间不允许通过二级索引更新热点记录	若通过二级索引更新正在被热点更新的记录，将报错并回滚整个事务。
暂不支持线程池模式	在开启线程池（Thread Pool）的实例上，热点更新功能暂不可用。

tencent cloud

云数据库 MySQL

热点更新增强：合并优化

功能简介

适用场景

功能原理

“热点更新：排队机制”方案的局限性

热点更新增强方案：事务合并（Group Commit）

关键机制

执行流程

正确性保证

1. 提交序保证

2. 回滚序保证

3. Crash Recovery

性能提升效果

TPS 对比

95th Percentile 延迟（ms）对比

参数说明

参数调整建议

使用限制

使用方式

开启热点更新

典型业务 SQL 示例

验证热点更新是否生效

注意事项

支持版本

相关文档

帮助和支持