在高并发业务场景下，同一行数据被大量并发请求同时更新时，就会触发SQL热点行更新问题，这会导致行锁竞争加剧，大量事务处于等待状态，严重时会拖慢整个数据库的性能。针对这类问题，热点数据拆分是最有效的优化手段之一。
SQL热点行更新的成因与影响
热点行更新的核心成因是大量并发请求同时操作同一行数据，常见的业务场景包括秒杀商品库存扣减、热门账号余额更新、高频计数器累加等。当这些操作发生时，数据库会对目标行加行锁，其他想要更新该行的请求只能等待锁释放，随着并发量上升，等待队列会越来越长。
其带来的影响主要有三类：
- 事务响应时间变长，用户请求超时概率升高
- 数据库CPU资源被大量锁等待消耗，整体吞吐量下降
- 极端情况下会引发死锁，甚至导致数据库实例不可用
热点数据拆分核心策略
1. 行级拆分策略
行级拆分的核心思路是将原本的单行热点数据拆分成多行，将更新请求分散到不同的行上，最后通过求和得到真实数据。以库存扣减场景为例，原本只有一个库存行，我们可以将其拆成多个子库存行。
首先创建拆分后的库存表：
-- 创建拆分库存表
CREATE TABLE split_product_stock (
id INT PRIMARY KEY AUTO_INCREMENT,
product_id INT NOT NULL COMMENT '商品ID',
sub_stock_id INT NOT NULL COMMENT '子库存编号',
stock_num INT NOT NULL COMMENT '子库存数量',
UNIQUE KEY uk_product_sub (product_id, sub_stock_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
插入初始数据，假设商品1001的总库存是1000，拆成10个子库存：
-- 初始化10个子库存，每个库存100 INSERT INTO split_product_stock (product_id, sub_stock_id, stock_num) VALUES (1001, 1, 100), (1001, 2, 100), (1001, 3, 100), (1001, 4, 100), (1001, 5, 100), (1001, 6, 100), (1001, 7, 100), (1001, 8, 100), (1001, 9, 100), (1001, 10, 100);
更新库存时，随机选择一个子库存进行扣减，扣减失败则重试其他子库存：
-- 随机扣减子库存，假设扣减数量为1 UPDATE split_product_stock SET stock_num = stock_num - 1 WHERE product_id = 1001 AND sub_stock_id = FLOOR(RAND() * 10) + 1 AND stock_num >= 1;
查询总库存时，对所有子库存求和即可：
-- 查询商品总库存 SELECT SUM(stock_num) AS total_stock FROM split_product_stock WHERE product_id = 1001;
2. 缓存层拆分策略
将热点数据的更新操作先放到缓存层执行，降低数据库的更新频率，也是常见的拆分思路。我们可以把热点数据的变更记录先存在Redis中，批量同步到数据库。
以计数器场景为例，使用Redis的INCR命令先更新缓存，再定期同步到数据库：
import redis.clients.jedis.Jedis;
public class HotCounter {
private Jedis jedis = new Jedis("127.0.0.1", 6379);
private static final String COUNTER_KEY = "hot_counter";
// 更新计数器，先更新缓存
public long incrementCounter() {
// 对热点计数器执行加1操作
return jedis.incr(COUNTER_KEY);
}
// 定期同步缓存数据到数据库
public void syncToDatabase() {
// 获取当前缓存中的计数器值
String counterValue = jedis.get(COUNTER_KEY);
if (counterValue != null) {
int value = Integer.parseInt(counterValue);
// 执行数据库更新操作，这里使用预编译语句避免SQL注入
String sql = "UPDATE counter_table SET count_num = ? WHERE counter_id = 1";
// 实际业务中使用JDBC或者ORM框架执行该SQL
System.out.println("同步计数器值到数据库：" + value);
}
}
}
3. 业务维度拆分策略
根据业务属性将热点数据拆分到不同的维度，比如按用户ID、地域、时间等维度拆分。以热门账号余额更新为例，可以按用户ID哈希拆分到不同的账户子表：
-- 创建账户子表，按用户ID哈希拆分到4张表
CREATE TABLE user_account_0 (
user_id INT PRIMARY KEY,
balance DECIMAL(10,2) NOT NULL COMMENT '账户余额'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE user_account_1 (
user_id INT PRIMARY KEY,
balance DECIMAL(10,2) NOT NULL COMMENT '账户余额'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE user_account_2 (
user_id INT PRIMARY KEY,
balance DECIMAL(10,2) NOT NULL COMMENT '账户余额'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE user_account_3 (
user_id INT PRIMARY KEY,
balance DECIMAL(10,2) NOT NULL COMMENT '账户余额'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
更新时根据用户ID的哈希值选择对应的子表：
-- 假设用户ID是101，哈希计算后到user_account_1表更新余额 UPDATE user_account_1 SET balance = balance - 50 WHERE user_id = 101;
不同策略的适用场景对比
我们可以根据业务特点选择合适的拆分策略，以下是各策略的适用场景对比：
| 策略类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 行级拆分 | 库存扣减、计数器等数值类热点数据 | 实现简单，无需额外中间件 | 总数据查询需要额外求和，数据一致性稍弱 |
| 缓存层拆分 | 高频更新、允许短暂延迟的场景 | 性能提升明显，减轻数据库压力 | 需要引入缓存组件，存在缓存一致性问题 |
| 业务维度拆分 | 用户相关、地域相关的热点数据 | 拆分逻辑贴合业务，查询效率高 | 需要修改业务路由逻辑，跨维度查询复杂 |
注意事项
在使用热点数据拆分策略时，需要注意以下几点：
- 拆分后要保证数据的最终一致性，避免出现数据偏差
- 子数据的初始分配要合理，避免拆分后仍然出现新的热点
- 对于强一致性的业务场景，需要先评估拆分后的风险，必要时结合其他锁优化手段
热点数据拆分不是银弹，需要结合业务的并发量、数据特点、一致性要求综合选择方案，同时做好压测验证，确保优化效果符合预期。