GROUP BY本身不加锁，纯聚合查询走MVCC一致性读；但用于UPDATE子查询时，InnoDB按执行计划对扫描到的物理索引记录加临键锁，锁范围取决于是否命中索引、有无覆盖索引及聚合条件能否下推。
分组查询（GROUP BY）本身不加锁，但一旦参与更新（如子查询中嵌套 GROUP BY 再用于 UPDATE），锁行为就完全取决于底层扫描和匹配的行——而不是分组结果本身。
GROUP BY 不直接触发锁，但执行计划决定实际加锁范围
SELECT COUNT(*) FROM orders GROUP BY status 这类纯聚合查询在默认隔离级别下走一致性读（MVCC），不加任何锁。但只要它被用在写操作上下文中，比如作为子查询条件，InnoDB 就必须真实扫描并锁定涉及的索引记录。
- 例如：
UPDATE users SET flag = 1 WHERE id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5)—— 这里GROUP BY只是逻辑组织方式，InnoDB 实际执行时仍需全表/索引扫描orders表，对每条扫描到的索引记录加临键锁（Next-Key Lock），哪怕最终只有一小部分满足HAVING条件 - 关键看
EXPLAIN输出中的type：如果是ALL或index，说明没走有效索引，锁范围极大；如果是ref或range且key显示用了合适索引（如(user_id, status)覆盖索引），锁才可能收敛到少数行 - MySQL 不会对“分组结果集”加锁，它只对执行路径中访问到的**物理索引节点**加锁——哪怕某行因
HAVING被过滤掉，只要 B+ 树遍历经过它，就可能被锁住
UPDATE + 子查询含 GROUP BY 时容易锁表或锁间隙
这类语句是并发更新事故高发区，因为优化器常无法精确估算分组后要更新的目标行，被迫扩大扫描与加锁范围。
- 若子查询未显式关联主表（如缺少
WHERE orders.user_id = users.id条件），MySQL 可能退化为物化临时表 + 全量 join，导致对users表全表扫描并加行锁 - 若
orders表上user_id无索引，GROUP BY user_id必然触发全表扫描，InnoDB 对每一行都加 X 锁，等效于锁全表 - 即使有索引，
HAVING COUNT(*) > 5这种聚合过滤也无法下推到索引扫描层，引擎必须累积计数，期间持续持有已扫描行的锁，直到分组完成——持有时间远长于单行更新
替代方案：避免在 UPDATE 中实时计算分组逻辑
把聚合计算和更新动作拆开，既能控制锁粒度，也便于观察和重试。
- 先用带索引的条件查出目标 ID 列表：
SELECT user_id FROM orders WHERE created_at > '2026-05-01' GROUP BY user_id HAVING COUNT(*) > 5，确保EXPLAIN显示走了created_at或联合索引 - 将结果存入临时表或应用层缓存，再用
UPDATE users SET flag = 1 WHERE id IN (…)批量更新——此时 WHERE 是精确主键匹配，只锁目标行 - 更稳妥的做法是加主键范围分批：
UPDATE users SET flag = 1 WHERE id BETWEEN 1000 AND 2000 AND id IN (SELECT user_id FROM orders …)，配合事务提交，避免长事务持锁 - 如果业务允许轻微延迟，可用异步任务预计算分组结果并写入汇总表（如
user_order_stats），更新时直查该表，彻底避开运行时聚合
真正危险的不是 GROUP BY 语法本身，而是它掩盖了底层扫描的不可控性。只要执行计划出现全表扫描、没走覆盖索引、或聚合条件无法下推，锁就会从几行蔓延到几千行——而这些在开发阶段很难靠肉眼识别，必须依赖 EXPLAIN FORMAT=JSON 看 used_columns 和 access_type，以及在测试环境用 SHOW ENGINE INNODB STATUS 观察实际锁等待。
