GROUP BY子查询在UPDATE中会锁全表或间隙，因优化器无法下推HAVING条件且需扫描全表加临键锁；应拆分为三步：先索引查ID、存临时表、再窄范围更新，并确保WHERE命中索引。
直接在 UPDATE 语句里嵌套 GROUP BY 子查询做并发更新，几乎必然引发锁扩大、超时甚至数据错乱——这不是写法问题，而是执行模型决定的。
为什么 GROUP BY 子查询在 UPDATE 中会锁全表或锁间隙
MySQL/PostgreSQL 的优化器不会为“分组结果”加锁，只对实际扫描到的索引记录加锁。一旦 GROUP BY 出现在 UPDATE 的子查询中，引擎必须遍历原始表（或索引）完成聚合，期间对每条扫描行都持有临键锁（Next-Key Lock），哪怕最终被 HAVING 过滤掉。
-
EXPLAIN显示type: ALL或type: index：说明没走有效索引，InnoDB 对每一行都加 X 锁，等效锁全表 -
WHERE条件缺失关联主表（如orders.user_id = users.id）：优化器可能物化临时表 + 全量 join，导致users表被全表扫描并加行锁 - 即使有索引，
HAVING COUNT(*) > 5这类条件无法下推到索引层，引擎必须累积计数，锁持续持有直到分组结束——远长于单行更新
替代方案：把聚合和更新彻底拆开
核心是让锁只落在最终要更新的几行上，而不是整个聚合源表。先算出目标 ID 列表，再用这些 ID 做窄范围更新。
- 第一步：用带索引的条件查目标 ID，确保
EXPLAIN显示type: range或ref，且key明确命中联合索引（如(user_id, created_at)） - 第二步：把结果存入临时表（
CREATE TEMPORARY TABLE tmp_targets AS ...）或应用层缓存，避免重复计算 - 第三步：用
UPDATE ... WHERE id IN (SELECT id FROM tmp_targets)更新，此时锁只作用于明确的目标行 - 若需强一致性，整个三步操作包在
BEGIN TRANSACTION+REPEATABLE READ中，并在更新前加SELECT ... FOR UPDATE锁住目标行
UPDATE 中带聚合逻辑时，WHERE 条件必须命中索引
哪怕你已经拆开了聚合步骤，最后那条 UPDATE 如果 WHERE 不走索引，依然会触发全表扫描加锁。这是最容易被忽略的“二次踩坑点”。
- 检查
EXPLAIN UPDATE ...的key字段是否非NULL；若为NULL，说明没用上索引 - 联合索引顺序必须匹配查询条件：例如
WHERE user_id = ? AND status = ?，索引应建为(user_id, status)，而非反过来 - 避免在
WHERE中对字段用函数（如WHERE UPPER(email) = ?），否则索引失效，锁范围失控 - 字符串字段注意隐式转换：
status是VARCHAR但存了'active '和'active'，GROUP BY status会拆成两组，后续更新漏掉一半
真正难的不是写出能跑的 SQL，而是在高并发下让锁不扩散、不升级、不等待——所有聚合逻辑必须脱离写语句上下文，所有 WHERE 条件必须经过 EXPLAIN 验证，所有字符串分组字段必须提前清洗。
