SQL Server中GROUP BY需包含非聚合非分组列在索引KEY或INCLUDE中以避免回表；GROUP BY列必须为索引最左前缀，其余非聚合列应进INCLUDE；缺失则触发Key Lookup导致随机I/O性能骤降。
SQL Server中GROUP BY为什么需要包含列才能避免回表
因为SQL Server执行GROUP BY时，若索引不能覆盖SELECT中所有非聚合字段，就必须回到聚簇索引（或堆）查原始行——这就是回表。它不是“多查一次”那么简单，而是把原本可走索引扫描的查询，拖进随机I/O密集型路径，尤其在大表上性能断崖式下跌。
哪些列必须放进索引的INCLUDE部分
核心原则：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列覆盖全部字段
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本身在索引里
