高频更新字段应拆分至子表、异步化处理、使用无锁计数器及缩短事务粒度。例如将积分等统计字段移至user_stats表，用INSERT...ON DUPLICATE KEY UPDATE实现原子更新；通过Redis/Kafka队列批量合并写入；单事务仅含一条更新语句，避免跨表操作与长事务。
高频更新字段容易引发行锁、间隙锁甚至表锁升级，核心思路是“拆分热点、降低粒度、异步化、减少事务持有时间”。
把高频更新字段单独拆成子表
避免和主业务字段挤在一张表里。比如用户积分、阅读时长、点赞数这类统计型字段，与其放在 red">users 表中频繁 UPDATE，不如新建 user_stats 表，用 user_id 当主键或联合主键。
- 主表（users）只存稳定信息（姓名、注册时间等），读多写少，缓存友好
- 子表（user_stats）专做原子更新，可配合 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO 实现无锁自增
- 查询时通过 JOIN 或应用层两次查询获取完整数据，性能损失远小于锁等待
用“写队列 + 后台合并”替代实时更新
不是所有更新都必须立刻落库。对一致性要求不强的场景（如浏览量、分享次数），可先写入内存队列（Redis List / Kafka），再由消费者批量合并后定时刷库。
- 前端/服务层将 {user_id: 123, action: 'view'} 推入 Redis 队列
- 后台 Worker 每 5 秒拉取一批，按 user_id 分组聚合，生成 UPDATE user_stats SET views = views + N WHERE user_id IN (...)
- 单条 SQL 更新多行，大幅降低 QPS 和锁频次；即使失败也可重试，不影响前端响应
用无锁计数器替代直接 UPDATE
MySQL 8.0+ 支持原子函数，配合唯一索引可避开行锁。
- 建表时设 UNIQUE KEY (user_id)，确保单用户一行
- 执行：INSERT INTO user_stats (user_id, views) VALUES (123, 1) ON DUPLICATE KEY UPDATE views = views + 1;
- 该语句在存在记录时仅加“意向锁 + 行锁”，不触发间隙锁；若并发高，可加 WHERE 条件缩小扫描范围（如加时间分区字段）
控制事务粒度，绝不跨表更新高频字段
一个事务里同时更新 orders 和 user_stats，会让两个表的锁相互等待，极易死锁。
- 高频字段更新务必单独成事务，且越短越好——只含一条 UPDATE 或 INSERT ... ON DUPLICATE KEY UPDATE
- 禁止在事务中调用远程接口、发消息、查无关表；尤其避免 SELECT ... FOR UPDATE 锁住大范围数据后再更新
- 应用层做好幂等：用唯一业务号去重，允许重复提交但不重复计数
