为什么在SQL Server中GROUP BY排序列缺少包含列会导致回表？-SQL-PHP中文网

SQL Server中GROUP BY需包含非聚合非分组列在索引KEY或INCLUDE中以避免回表；GROUP BY列必须为索引最左前缀，其余非聚合列应进INCLUDE；缺失则触发Key Lookup导致随机I/O性能骤降。

为什么在sql server中group by排序列缺少包含列会导致回表？

因为SQL Server执行GROUP BY时，若索引不能覆盖SELECT中所有非聚合字段，就必须回到聚簇索引（或堆）查原始行——这就是回表。它不是“多查一次”那么简单，而是把原本可走索引扫描的查询，拖进随机I/O密集型路径，尤其在大表上性能断崖式下跌。

核心原则：SELECT列表里所有**非聚合、非GROUP BY列**，都得出现在索引定义中——要么作为键列（KEY），要么作为包含列（INCLUDE）。但GROUP BY列必须是索引最左前缀，不能塞进INCLUDE。

SELECT status, user_id, AVG(amount) FROM orders WHERE created_at > '2026-10-01' GROUP BY status → status是GROUP BY列，必须放索引开头；user_id是非聚合非分组列，必须进INCLUDE；amount是聚合列，也建议放进INCLUDE避免回表取值
如果user_id被漏掉，SQL Server即使走了INDEX idx_status (status)，仍要对每个status分组结果逐条回聚簇索引找user_id，Extra里会出现Key Lookup
INCLUDE列不参与排序和查找，只存数据，所以加它几乎不影响写入性能，但能彻底消除回表

KEY列顺序受最左前缀严格约束，而GROUP BY + WHERE组合常导致字段角色冲突。比如：

WHERE user_id = 123 AND status = 'paid' GROUP BY status → 理想索引是(user_id, status)，但SELECT user_id, status, COUNT(*)中user_id只是过滤用，不是分组依据；若再要查created_at，它既不适合放KEY中间（破坏最左前缀），又不能丢——只能进INCLUDE
把created_at硬塞进KEY末尾变成(user_id, status, created_at)，会导致索引体积暴涨，且对GROUP BY status无加速作用（user_id等值过滤后，status已无序）
SQL Server不会为INCLUDE列建统计信息，所以它只解决“取数”，不解决“筛选”——筛选逻辑仍由KEY列承担

看执行计划里有没有Key Lookup操作符，比看Index Seek是否命中更直接。同时检查属性窗口中的Output List：里面列出的所有列，都必须在索引的KEY或INCLUDE中完整出现。

建索引后跑EXPLAIN（实际用SET STATISTICS XML ON），确认Index Scan/Seek节点的Output List不含未索引列
如果SELECT里有TEXT、XML或MAX类型字段，SQL Server不允许它们进INCLUDE，这时只能改查询（如用LEFT(body, 8000)代替body）或接受回表
最容易被忽略的是：把datetime字段当DATE用（如WHERE CAST(create_time AS DATE) = '2026-11-01'），这会让整个索引失效——哪怕create_time本身在索引里