必须用CREATE TYPE预定义内存优化表类型，再DECLARE实例化，因SQL Server语法禁止直接在DECLARE中使用MEMORY_OPTIMIZED=ON；否则报“Incorrect syntax near 'AS TABLE'”错误。
直接用内存优化表替代临时表或中间结果表，能在本机编译存储过程中把写入速度提上去，但前提是必须满足四个硬约束：类型要预定义、过程得是 NATIVE_COMPILATION、表必须设 DURABILITY = SCHEMA_ONLY、哈希索引的 bucket_count 得估准。跳过任意一条，不是报错就是白忙活。
为什么普通 DECLARE @t TABLE(...) 加 WITH (MEMORY_OPTIMIZED = ON) 会报错
SQL Server 就不认这种写法——语法层面禁止内联声明内存优化表变量。Incorrect syntax near 'AS TABLE' 是最常见错误。它强制你走两步：先用 CREATE TYPE 定义类型，再用 DECLARE 实例化变量。
这么做不是为了添麻烦，而是为了让类型在编译期就固化结构和索引，避免运行时动态解析开销。如果你在部署脚本里漏了 CREATE TYPE，或者把它放在存储过程里执行，那第一次调用就会卡住编译，拖垮并发。
示例必须这样写：
CREATE TYPE dbo.tvp_fast_write AS TABLE ( id INT INDEX ix_id HASH WITH (bucket_count = 10000), payload NVARCHAR(4000) ) WITH (MEMORY_OPTIMIZED = ON);
之后才能在本机编译过程中用：
DECLARE @data dbo.tvp_fast_write;
只在 NATIVE_COMPILATION 存储过程中才真正快起来
内存优化表变量在普通 T-SQL 里操作，性能几乎没提升，甚至更慢——因为多了类型校验和路径切换开销。只有 WITH NATIVE_COMPILATION, SCHEMABINDING 的过程，才能把整个执行链路编译成机器码，绕过查询优化器和解释器。
几个关键限制必须同步满足：
-
ATOMIC块里指定TRANSACTION ISOLATION LEVEL = SNAPSHOT，不能用READ COMMITTED - 过程里只能访问内存优化对象，混用磁盘表会直接报错
- 不能用
EXEC或sp_executesql动态 SQL - 不能用游标、
PRINT、RAISERROR（除THROW外）
换句话说：这不是“加个开关就能提速”，而是换了一套执行模型。高频写入场景（如日志聚合、订单拆单）适合，但通用逻辑别硬套。
bucket_count 设太小或太大都会翻车
哈希索引靠 bucket_count 分桶，它不是“越大越好”。桶太少，冲突链变长，查找退化成遍历；桶太多，内存浪费，还可能触发 GC 压力。
真实建议是：
- 按预期唯一键数量的 1–2 倍起步，比如预计插入 5 万行不同
id，就设bucket_count = 100000 - 上限可放宽到 10 倍，但别盲目填
1000000——除非你真有百万级唯一值 - 非等值查询（比如
BETWEEN、>）必须配NONCLUSTERED索引，但它每行多占 8–16 字节，写入密集时慎用
查不到索引命中？先看执行计划里有没有 “Index Seek (Hash)”；如果只有 “Table Scan”，八成是 bucket_count 没设或设错了。
SCHEMA_ONLY 是临时场景唯一正确选项
写入中间结果，必须用 DURABILITY = SCHEMA_ONLY。用 SCHEMA_AND_DATA 看似“数据不丢”，实则灾难：它会写事务日志、占持久内存、触发后台 GC，完全抵消内存优势，还可能因内存不足直接失败。
注意两个实操细节：
-
SCHEMA_ONLY表不能在运行时CREATE TABLE ... WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)—— 这种建表动作本身就会引发严重编译延迟 - 它必须在部署阶段一次性建好，比如
CREATE TABLE dbo.staging_orders (...) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)
真正该被替换掉的，是那些 ##temp 全局临时表或反复 INSERT INTO @table 的中间集合。只要结构稳定、生命周期短，SCHEMA_ONLY 就是最轻量、最可控的选择。
最后提醒一句：内存优化没有“自动内存管理”。它不会像 buffer pool 那样淘汰冷数据，一旦分配就常驻——所以 bucket_count 和行大小必须提前算清楚，否则 OOM 不是警告，是直接中断。
