内存优化表不支持SELECT中实时聚合的高性能执行，需依赖原生编译存储过程或非聚集列存储索引；哈希索引仅优化等值查找，全表扫描类聚合（如COUNT/SUM/GROUP BY）会退化为逐行遍历，且行版本可见性校验增加开销。
内存优化表本身不支持直接在 SELECT 中做实时聚合（如 SUM()、COUNT(*)）并保持高性能，除非配合原生编译存储过程或列存储索引——这是最容易被忽略的前提。
为什么普通 SELECT + 内存优化表做聚合会变慢
内存优化表默认使用行存储 + 哈希索引，适合点查和高并发写入，但对全表扫描类操作（比如 GROUP BY、SUM()）没有优化：哈希索引只加速等值查找，无法跳过无关行；所有行仍需逐个读取、解包、计算。实测中，千万级内存优化表执行 SELECT COUNT(*) FROM t 可能比磁盘表还慢。
- 哈希索引不支持范围扫描或排序，
ORDER BY或GROUP BY字段若没建非聚集索引，就会退化为全内存遍历 - 内存优化表的行版本结构（含 begin_ts/end_ts）增加了解析开销，聚合时每行都要校验可见性
- 未启用原生编译的 T-SQL 模块访问内存优化表，仍走解释执行路径，无法利用 CPU 寄存器级优化
用原生编译存储过程封装聚合逻辑
这是最可靠、性能提升最显著的方式。原生编译把聚合逻辑编译成机器码，绕过解释器，并能内联访问内存优化表的二进制布局。
- 必须用
WITH NATIVE_COMPILATION, SCHEMABINDING声明，且只能引用内存优化表 - 事务隔离级别固定为
SNAPSHOT，不能用READ COMMITTED - 不支持
SELECT *或动态 SQL，字段名和类型必须显式写出 - 示例：对订单流水按小时统计笔数和金额
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
给内存优化表加非聚集列存储索引
如果聚合查询是分析型为主（如 BI 报表拉取），且数据变更频率不高，直接在内存优化表上建 NONCLUSTERED COLUMNSTORE INDEX 是更轻量的选择——它不改变表结构，却让聚合走批模式（batch mode）执行，速度提升常达 10x 以上。
- 列存储索引是副本，不干扰 OLTP 写入路径，但会额外占用内存
- 必须确保内存优化表的
DURABILITY是SCHEMA_AND_DATA（不能是SCHEMA_ONLY） - 建索引后，SQL Server 会自动选择是否用列存储执行聚合，可通过执行计划确认是否出现
Columnstore Index Scan - 命令示例：
CREATE NONCLUSTERED COLUMNSTORE INDEX IX_CS_Orders ON dbo.Orders_InMemory (OrderTime, Amount, Status);
别忘了表变量也能加速临时聚合
如果你的“实时聚合”其实是中间计算（比如先过滤再分组再 Join），用内存优化表变量比临时表快得多，且无 tempdb 争用。
- 必须先用
CREATE TYPE定义类型，再DECLARE，不能内联声明 - 必须带索引（哈希或非聚集），哪怕只是单字段主键
- 作为 TVP 传入原生编译存储过程时，性能最优
- 示例定义：
CREATE TYPE dbo.OrderSummaryType AS TABLE (
HourOfDay TINYINT NOT NULL INDEX ix_hourofday NONCLUSTERED,
OrderCount INT NOT NULL,
TotalAmount DECIMAL(18,2) NOT NULL
) WITH (MEMORY_OPTIMIZED = ON);
真正卡住多数人的，不是不会建内存优化表，而是默认以为“放内存里就自动快”，结果聚合一跑就慢。关键得看操作类型：点查靠哈希索引，聚合靠列存或原生编译——两者机制完全不同，混用反而拖累。
