UPDATE热点行卡表因锁升级、长事务或死锁；应走索引、用ON DUPLICATE KEY UPDATE、分片拆解、降隔离级别至READ COMMITTED，并避免业务聚合。
为什么 UPDATE 热点行会卡住整个表？
MySQL 中热点行（比如用户余额、商品库存）被高频 UPDATE 时，InnoDB 默认用行锁，但实际可能升级为间隙锁或临键锁，尤其在 WHERE 条件没走索引、或使用范围查询时。更常见的是：事务持有锁时间过长（比如先查再算再更新）、或多个事务按不同顺序更新多行，引发死锁重试，进一步拖慢吞吐。
- 确认是否真锁了行：查
SELECT * FROM performance_schema.data_locks（MySQL 8.0+），或SHOW ENGINE INNODB STATUS里的TRANSACTIONS和LOCK WAIT部分 - 检查执行计划：
EXPLAIN UPDATE ...看是否走了主键/唯一索引；没走索引就会锁全表扫描涉及的所有行 - 避免在事务里做 HTTP 调用、文件读写等外部耗时操作
用 INSERT ... ON DUPLICATE KEY UPDATE 替代先查后更新
典型错误模式是：先 SELECT balance FROM accounts WHERE id = 123，再算新值，再 UPDATE accounts SET balance = ? WHERE id = 123。这中间有竞态窗口，且两次网络往返放大延迟。
改成单条语句原子更新，既减少锁持有时间，又消除读-改-写竞争：
INSERT INTO accounts (id, balance) VALUES (123, 100) ON DUPLICATE KEY UPDATE balance = balance + VALUES(balance);
- 要求
id是主键或唯一索引，否则ON DUPLICATE KEY不生效 - 不能用于需要条件判断的场景（比如“余额不足则不扣”），此时得用
SELECT ... FOR UPDATE加应用层校验 - 注意
VALUES()函数只在INSERT ... ON DUPLICATE KEY中有效，不是通用函数
拆分热点行：用哈希分片降低单行压力
如果无法避免高频更新同一逻辑行（如全局计数器），可把一个值拆成 N 个物理行，写入时随机选一个，读取时汇总。例如库存从单字段 stock 拆为 stock_0 到 stock_7 共 8 行：
UPDATE inventory_shard SET stock = stock + 1 WHERE item_id = 456 AND shard_id = FLOOR(RAND() * 8);
- 分片数不宜过多（一般 4–16），否则
SUM()聚合成本上升 - 读操作必须用
SELECT SUM(stock) FROM inventory_shard WHERE item_id = 456，不能只读某一分片 - 分片键（如
shard_id）要加复合索引(item_id, shard_id)，避免全表扫描
用 READ COMMITTED 隔离级别减少锁范围
默认的 REPEATABLE READ 在范围查询时会加临键锁（Next-Key Lock），容易锁住不该锁的间隙。对热点行更新为主的场景，降级到 READ COMMITTED 可让 InnoDB 只锁匹配到的行，不锁间隙：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
- 必须确保业务能接受“不可重复读”——比如两次读同一行得到不同值，不影响最终一致性
- 该设置对当前 session 生效，不要全局改
transaction_isolation，避免影响其他模块 - 即使设为
READ COMMITTED，UPDATE ... WHERE仍会锁住所有扫描过的行（如果没走索引，还是全表锁）
真实压测中，单行 QPS 过 500 就该警惕；超过 2000 基本说明设计已越界。拆分和隔离级别调整见效快，但最根本的，是别让数据库扛业务层的聚合逻辑。
