必须预先创建内存优化表，不可在存储过程中动态创建；访问时需显式指定SNAPSHOT隔离级别；表变量须先建类型并含索引；本机编译存储过程仅支持内存优化表且语法受限。
必须先创建内存优化表，不能在存储过程中动态建表
SQL Server 不允许在存储过程里用 CREATE TABLE 创建内存优化表——哪怕只是临时用途。这是因为内存优化表的结构编译时需固化，而解释型 T-SQL 存储过程无法在运行时完成内存结构注册和索引初始化。你看到的“对象名无效”或“不支持此操作”错误，往往就卡在这一步。
正确做法是：提前在数据库中创建好内存优化表（DURABILITY = SCHEMA_AND_DATA 或 SCHEMA_ONLY），然后在存储过程中直接 INSERT/UPDATE/SELECT 它。若用于缓存或会话级暂存，推荐用 DURABILITY = SCHEMA_ONLY 配合唯一索引，避免磁盘 I/O 和持久化开销。
- 不要写：
CREATE TABLE #tmp (...) WITH (MEMORY_OPTIMIZED = ON)—— 语法直接报错 - 可以写：
INSERT INTO dbo.CacheTable VALUES (...)，前提是CacheTable已存在且是内存优化的 - 若需多会话隔离，别依赖
#temp语义，改用带@@spid过滤列 +CHECK约束的SCHEMA_ONLY表
显式事务中访问内存优化表必须指定隔离级别
在 BEGIN TRANSACTION 块里操作内存优化表时，SQL Server 默认不会自动提升隔离级别。如果不显式声明快照隔离，会触发错误 41302（“当前事务无法访问内存优化表…”）或静默降级为阻塞行为，失去乐观并发优势。
有两种等效解法：
- 全局启用：
ALTER DATABASE YourDB SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON（推荐，一劳永逸） - 语句级指定：
SELECT * FROM dbo.MyMemTable WITH (SNAPSHOT)，或在FROM子句加WITH (SNAPSHOT)提示 - 注意：
READ COMMITTED对内存优化表无效，强制要求SNAPSHOT或REPEATABLE READ及以上
想用表变量？必须先建类型，再声明变量
内存优化表变量不能像普通表变量那样内联声明：DECLARE @t TABLE (...) 会失败。它必须走两步：先用 CREATE TYPE 定义一个内存优化的表类型，再用该类型声明变量。
典型错误是漏掉索引——每个内存优化表类型都**必须包含至少一个索引**（HASH 或 NONCLUSTERED），否则 CREATE TYPE 直接报错。
- 正确示例：
CREATE TYPE dbo.OrderList AS TABLE ( OrderId INT NOT NULL INDEX ix_hash HASH (OrderId) WITH (BUCKET_COUNT = 1024), Qty INT ) WITH (MEMORY_OPTIMIZED = ON);
- 然后才能：
DECLARE @orders dbo.OrderList - 哈希索引的
BUCKET_COUNT建议设为预期唯一键数量的 1–2 倍；过高浪费内存，过低引发链式查找退化
本机编译存储过程能获得最大收益，但限制极多
如果性能瓶颈真在存储过程执行路径上，应优先考虑把逻辑迁移到本机编译存储过程（WITH NATIVE_COMPILATION）。它绕过查询优化器，直接生成机器码，对内存优化表的访问延迟可降至微秒级。
但代价明显：语法受限（不支持 CTE、子查询嵌套、EXEC 动态 SQL）、调试困难、修改需 DROP/CREATE。更重要的是——它**只能访问内存优化表**，不能混用磁盘表。
- 常见坑：
SELECT * FROM dbo.MemTable JOIN dbo.DiskTable ON ...在本机编译过程里非法 - 所有引用的表、类型、函数都必须提前存在，且不能是临时对象
- 首次执行会有编译延迟（毫秒级），不适合低频、偶发调用场景
真正难处理的不是语法，而是内存压力反馈滞后：表数据量增长后，可能某次 INSERT 突然失败并报“资源池内存不足”，但 sys.dm_db_xtp_table_memory_stats 显示使用率才 60%。这通常意味着索引版本链膨胀或 GC 线程跟不上写入节奏——得查 xtp_gc_queue_stats 和等待类型 XTP_LOGGER_WAIT。
