热点账户更新慢的本质是多事务争抢同一行x锁导致串行化瓶颈，需通过分片、缓冲记账、锁优化及最终一致性方案解决。
热点账户更新慢，本质是多个事务争抢同一行记录的排他锁（X锁），形成串行化瓶颈。不是SQL写得不对，而是架构和执行方式没跟上并发规模。
把“单点压力”打散：库存/余额分片
别让所有扣款都指向account(id=1001, balance=5000)这一行。改成虚拟分片设计：
- 建子表
account_balance_shard(user_id, shard_id, amount)，主键为(user_id, shard_id) - 初始化时把5000元拆成10份，每份500元，shard_id从0到9
- 每次扣款随机选一个shard_id执行
UPDATE ... SET amount = amount - 100 - 查总余额用
SELECT SUM(amount) FROM account_balance_shard WHERE user_id = 1001
10个分片可降低约90%的锁冲突，且无需改业务逻辑主干。
用缓冲记账代替实时更新
高频写入不直接碰核心账户，先落轻量流水表：
- 插入缓冲表
buffer_tx(user_id, op_type, amount, tx_id, status)，纯INSERT无锁，支持10万+ TPS - 异步服务每10秒聚合：
SELECT user_id, SUM(amount) FROM buffer_tx WHERE status='pending' GROUP BY user_id - 批量更新核心账户：
UPDATE account SET balance = balance + ? WHERE id = ?，一次更新N个用户 - 前端展示余额 = 核心余额 + 未合并的缓冲变动（查buffer_tx实时聚合）
锁操作必须精准、短时、可控
避免自以为优化实则放大争用：
- 删掉事务里所有非DB操作：HTTP调用、日志打印、复杂计算——这些会拖长锁持有时间
-
SELECT ... FOR UPDATE只在真正要更新前一刻执行，绝不提前加锁 - WHERE条件必须走索引：字段类型匹配、不隐式转换、不写
WHERE DATE(create_time)=...这类函数 - MySQL 8.0+ 可加
FOR UPDATE WAIT 1，超1秒直接失败，防无限挂起
接受短暂不一致，换系统稳定性
对秒杀、红包等场景，强一致性不是刚需，可用Redis+消息队列解耦：
- 用Redis Lua脚本原子扣减：
DECRBY balance_key 100，成功才放行 - 失败直接返回，不穿透到MySQL
- 成功后发MQ消息，消费端控制速率（如300条/秒）异步落库
- 消息体带唯一
tx_id，DB层用INSERT IGNORE或ON DUPLICATE KEY UPDATE防重
用户看到“已发放”，数据库延迟几十毫秒写入，体验无感，系统稳如磐石。
