内存优化表变量仅在本机编译存储过程中生效，需先用CREATE TYPE显式定义MEMORY_OPTIMIZED类型并指定DURABILITY与索引，不可内联声明；普通存储过程使用无效且可能更慢。
直接在普通存储过程中用 DECLARE @t TABLE (...) WITH (MEMORY_OPTIMIZED = ON) 是无效的——SQL Server 2019 不支持这种写法，也不会提速。真正能带来性能跃升的组合，只在「本机编译存储过程 + 预定义内存优化表类型」下成立，且必须严格匹配使用场景。
必须先 CREATE TYPE，不能内联声明内存优化表变量
内存优化表变量不是普通表变量的“开关式升级”，而是类型系统级约束。你无法像写 DECLARE @t TABLE (id INT) 那样直接加 WITH (MEMORY_OPTIMIZED = ON) ——这会报错 Incorrect syntax near 'AS TABLE'。
正确路径只有两步：
- 用
CREATE TYPE显式定义类型，必须带MEMORY_OPTIMIZED = ON和明确的DURABILITY - 在本机编译存储过程中，用
DECLARE @var dbo.your_type_name实例化
例如：
CREATE TYPE dbo.tvp_order_summary AS TABLE ( order_id INT INDEX ix_oid HASH WITH (bucket_count = 10000), total DECIMAL(18,2) ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
之后才能在本机编译过程中使用它。跳过 CREATE TYPE 这一步，一切免谈。
只在 NATIVE_COMPILATION 存储过程中生效
内存优化表变量的零锁、无页分裂、哈希直查等优势，只在本机编译（NATIVE_COMPILATION）上下文中兑现。普通解释型存储过程里操作它，SQL Server 仍走传统执行器路径，不仅不提速，还会因类型检查和桥接开销略慢。
启用本机编译还需满足两个硬性条件：
- 必须指定
SCHEMABINDING - 过程体内只能引用内存优化对象（不能混用磁盘表、临时表或普通变量）
这意味着：你想加速一个含复杂 JOIN 和多个临时中间结果的旧过程？不能直接改，得拆出纯内存优化逻辑段，单独封装为本机编译过程，再由主过程调用。
选对 DURABILITY 和索引类型，否则白忙活
DURABILITY = SCHEMA_ONLY 是替代 @table 或 ##temp 的唯一合理选项。它不写日志、不占持久内存、重启即清空，完全匹配中间计算场景。若误设为 SCHEMA_AND_DATA，每次 INSERT 都触发日志写入和垃圾回收，性能反被拖垮。
索引选择也直接影响效果：
- 等值查询（如
WHERE id = @x）优先用HASH索引，但bucket_count必须预估准确：设为预期行数的 1–2 倍较稳妥；填 1000000 却只存 100 行，浪费内存且降低缓存效率 - 需要
ORDER BY或范围扫描（如WHERE ts BETWEEN @s AND @e），必须建NONCLUSTERED索引，但它会让每行多占约 8–16 字节，高频插入时需权衡
没有索引的内存优化表，查询就是全表扫描，比磁盘表还慢——因为少了缓冲池预读优化。
内存不足时不会优雅降级，必须提前算清楚
内存优化对象不参与 SQL Server 的缓冲池管理，也没有 LRU 淘汰机制。一旦分配的内存超限，SQL Server 会直接报错 Memory limit exceeded for memory-optimized tables，而不是把部分数据刷到磁盘。这个限制是实例级的，由 MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 和资源调控器共同控制。
所以部署前必须估算：
- 每行平均大小 × 最大预期行数 × 1.3（MVCC 版本链开销）
- 加上哈希索引结构本身占用（每个
HASH索引约额外消耗 8MB / 100 万 bucket）
漏掉这个步骤，上线后高并发一压，不是慢，是直接失败。
