内存优化表本身不加速普通SELECT聚合，反而更慢；真正提速方式只有原生编译存储过程或非聚集列存储索引。
直接说结论：内存优化表本身不加速普通 SELECT 中的聚合（如 COUNT(*)、SUM()、GROUP BY），反而可能更慢；真正能提速的只有两种方式——用原生编译存储过程封装聚合逻辑，或加非聚集列存储索引。其他所有尝试（比如只建哈希索引、改隔离级别、加大内存）都无效。
为什么普通 SELECT + 内存优化表做聚合反而变慢
内存优化表的底层设计目标是高并发点查和写入，不是分析型扫描：
- 哈希索引只优化
=查找，对GROUP BY或全表COUNT(*)无加速作用，引擎仍需逐行遍历所有数据 - 每行带
begin_ts/end_ts版本字段，聚合时必须校验可见性，开销比磁盘表还高 - 未启用原生编译的 T-SQL（比如直接在 SSRS 或报表工具里写
SELECT SUM(Amount) FROM Orders_InMemory）走解释执行路径，完全无法利用内存布局优势 - 实测：千万级
Orders_InMemory表执行SELECT COUNT(*)，耗时可能是等价磁盘表的 2–3 倍
必须用原生编译存储过程才能发挥性能
这是唯一能绕过解释器、直接生成机器码访问内存结构的方式。但约束极多，稍错就编译失败：
- 必须显式声明
WITH NATIVE_COMPILATION, SCHEMABINDING - 事务隔离级别只能是
SNAPSHOT，不能用READ COMMITTED - 不支持
SELECT *、动态 SQL、子查询、窗口函数、CROSS APPLY - 所有字段名和类型必须硬编码，不能依赖视图或别名推导
- 示例中
DATEPART(HOUR, OrderTime)是允许的，但CONVERT(VARCHAR, OrderTime, 120)会报错
CREATE PROCEDURE dbo.GetHourlyStats_Native @StartDT DATETIME2(0)
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
SELECT DATEPART(HOUR, OrderTime) AS HourOfDay,
COUNT(*) AS OrderCount,
SUM(Amount) AS TotalAmount
FROM dbo.Orders_InMemory
WHERE OrderTime >= @StartDT
GROUP BY DATEPART(HOUR, OrderTime)
END
非聚集列存储索引是更轻量的替代方案
如果报表以读为主、写入频率低（比如每小时批量导入一次），直接在内存优化表上建 NONCLUSTERED COLUMNSTORE INDEX 是最省事的选择：
- 它不改变原表结构，也不影响 OLTP 写入路径（列存索引是副本）
- 聚合查询自动走批处理模式（batch mode），
SUM/COUNT/GROUP BY性能常提升 5–10 倍 - 注意：会额外占用内存（约等于原表 30%–50% 的内存空间）
- SQL Server 2019 支持在内存优化表上直接创建，无需升级到 2022 或更高版本
- 建索引语句示例：
CREATE NONCLUSTERED COLUMNSTORE INDEX IX_CS_Orders ON dbo.Orders_InMemory (OrderTime, Amount);
最容易被忽略的一点：这两种方案互斥——一旦加了列存储索引，原生编译存储过程里再引用该表，就会因元数据冲突而编译失败。生产环境上线前，必须明确选边：高频实时聚合用原生编译；BI 类定时报表优先列存储索引。
