GROUP BY 本身不能消除死锁，反而在不当使用时会加剧锁竞争；其易引发死锁主因是缺乏索引导致执行计划退化、全表扫描、锁范围失控及与DML共存时锁持有时间拉长。
GROUP BY 本身不能消除死锁，反而在不当使用时会加剧锁竞争——它不控制加锁顺序，也不减少锁持有时间，更不改变事务隔离级别。
为什么 GROUP BY 查询容易卷入死锁
死锁常发生在多个事务以不同顺序访问相同资源时。GROUP BY 查询若缺乏索引支撑或混用 JOIN/子查询，会导致：
- 执行计划退化为
Hash Match Aggregate+Sort→ 扫描大量原始行 → 持有大量页锁甚至表锁 - WHERE 条件未走索引（如
WHERE UPPER(name) = 'ABC'）→ 全表扫描 → 锁范围失控 - 与 UPDATE/DELETE 语句共存于同一事务中，且 GROUP BY 结果被后续 DML 引用（如用聚合结果驱动更新）→ 锁持有时间拉长、路径不可控
- 显式
HOLDLOCK或UPDLOCK与 GROUP BY 组合 → 提前升级并固化锁粒度，放大冲突概率
真正能降低死锁风险的 GROUP BY 写法
核心是让 SQL Server 用 Stream Aggregate 替代哈希或排序聚合，从而实现索引顺序流式分组，避免全量扫描和中间结果集锁。
- 建覆盖索引，字段顺序必须严格匹配：WHERE 字段最左 → GROUP BY 字段次之 → SELECT 中的聚合列用
INCLUDE - 示例索引：
CREATE NONCLUSTERED INDEX IX_orders_status_region ON orders (status, region) INCLUDE (price); - 对应查询必须保持字段顺序一致：
SELECT region, SUM(price) FROM orders WHERE status = 'shipped' GROUP BY region ORDER BY region; - 禁止在 GROUP BY 或 WHERE 中使用函数、表达式，否则索引失效，触发扫描
- 避免
SELECT *或非索引字段参与聚合，否则强制回表 → 打断流式路径 → 锁扩散
GROUP BY 和 UPDATE 共存时的死锁避坑点
当业务需要“先统计再更新”（如按区域汇总后更新订单状态），直接嵌套会导致锁顺序混乱。正确做法是拆离聚合与修改逻辑：
- 第一步：用窄查询 +
ORDER BY+ 索引驱动取分组键，例如：SELECT DISTINCT region FROM orders WHERE status = 'pending' ORDER BY region; - 第二步：将结果存入表变量或临时表，确保后续 UPDATE 按固定顺序访问
orders表 - 第三步：UPDATE 使用显式 JOIN，而非子查询：
UPDATE o SET status = 'processing' FROM orders o INNER JOIN #regions r ON o.region = r.region; - 关键约束：所有涉及
orders的 DML 必须统一按region（或主键）顺序加锁，且该顺序由索引保证
最容易被忽略的是：GROUP BY 查询本身虽不修改数据，但它持有的共享锁（S 锁）可能与并发 UPDATE 的更新锁（U 锁）形成等待链；而一旦聚合过程因缺失索引变慢，这个等待窗口就被拉长，死锁概率指数上升。所以不是“用了 GROUP BY 就要防死锁”，而是“没索引支撑的 GROUP BY，本身就是死锁温床”。
