为什么 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 基本说明设计已越界。拆分和隔离级别调整见效快，但最根本的，是别让数据库扛业务层的聚合逻辑。
