GROUP BY子查询在UPDATE中会锁全表，因为优化器需扫描原始表聚合，对每条索引记录加临键锁，且HAVING条件无法下推、缺少关联条件会导致物化临时表和全表扫描；应拆解为三步：先用索引查ID列表，再存临时表或缓存聚合结果，最后窄范围更新，并确保UPDATE的WHERE命中索引。
GROUP BY 本身不加锁，但一旦出现在 UPDATE 的子查询里，就会引发严重并发写入冲突——不是语法报错，而是锁范围失控、超时频发、数据更新漏掉或重复。
为什么 GROUP BY 子查询在 UPDATE 中会锁全表
MySQL/PostgreSQL 执行 UPDATE ... WHERE id IN (SELECT ... GROUP BY ...) 时，优化器必须扫描原始表完成聚合，对**每条扫描到的索引记录**加临键锁（Next-Key Lock），哪怕最终被 HAVING 过滤掉。
-
EXPLAIN显示type: ALL或type: index→ 没走有效索引，等效锁全表 -
HAVING COUNT(*) > 5这类条件无法下推到索引层，引擎边扫边计数，锁持有时间远长于单行更新 - 子查询未显式关联主表（如缺少
orders.user_id = users.id）→ 优化器物化临时表 + 全量 join，users 表被全表扫描加锁
替代方案：三步拆解，把锁缩到目标行
核心是让聚合计算和行级更新彻底分离，锁只落在最终要改的几行上。
- 第一步：用带索引的条件查 ID 列表，确保
EXPLAIN的key非空，type是range或ref（例如索引(user_id, created_at)，查询条件含WHERE created_at > ?） - 第二步：存入临时表：
CREATE TEMPORARY TABLE tmp_ids AS SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5；或应用层缓存结果（避免重复计算） - 第三步：窄范围更新：
UPDATE users SET flag = 1 WHERE id IN (SELECT id FROM tmp_ids)—— 此时锁只作用于明确的目标行
UPDATE 的 WHERE 条件必须命中索引
这是最容易被忽略的“二次踩坑点”：就算你已拆开聚合步骤，最后那条 UPDATE 若 WHERE 不走索引，依然触发全表扫描加锁。
- 检查
EXPLAIN UPDATE ...的key字段是否非NULL；若为NULL，说明没用上索引 - 联合索引顺序必须匹配查询条件，例如
WHERE user_id = ? AND status = ?，索引应建为(user_id, status)，而非反过来 - 避免在
WHERE中对字段用函数（如UPPER(email)），否则索引失效，锁范围失控 - 字符串字段注意尾部空格等隐式差异：
status是VARCHAR但存了'active '和'active'，GROUP BY status会拆成两组，后续更新漏掉一半
真正难的不是写出能跑的 SQL，而是让锁不扩散、不升级、不等待——所有聚合逻辑必须脱离写语句，在可控范围内先算出目标集。
