表变量更轻量因不写日志、无锁管理、作用域独立，高并发下避免tempdb争用；适用数据≤500行、单次过滤/更新、无需统计信息场景。
表变量 vs 临时表：为什么并发时表变量更轻量
表变量（@table）在 SQL Server 中默认不写入 tempdb 日志，也不参与锁管理，每次声明都是独立作用域内的内存结构（实际可能溢出到 tempdb，但无锁争用）。而临时表（#temp）会生成物理对象、触发 tempdb 页分配、记录日志、参与锁升级——高并发下极易出现 tempdb 争用、PAGELATCH_UP 等等待。电商秒杀场景中，1000 并发调用同一存储过程，用 #temp 可能导致 tempdb 文件头争用，而 @table 基本无此问题。
什么时候必须用表变量？三个硬性条件
不是所有中间结果都适合表变量。以下情况应优先选 @table：
- 数据量稳定且 ≤ 500 行（优化器对表变量的“1 行假设”影响小）
- 仅用于单次 JOIN 或 WHERE 过滤，不反复读取或排序
- 不需统计信息驱动执行计划（例如：只做简单 UPDATE 或 INSERT INTO … SELECT）
反例：不要在循环内反复 INSERT 到同一个 @table 累积数万行；也不要对 @table 执行 ORDER BY + TOP 分页——这时优化器大概率选错连接方式，性能反而更差。
内存优化表变量：SQL Server 2014+ 的真正并发加速器
普通表变量仍是传统引擎路径，而内存优化表变量（MEMORY_OPTIMIZED = ON）彻底绕过 tempdb 和锁机制，纯内存操作。但它有强制约束：
- 必须先用
CREATE TYPE预定义类型，不能内联声明：CREATE TYPE dbo.ProductUpdateList AS TABLE ( ProductID INT NOT NULL INDEX ix_hash HASH(ProductID) WITH (BUCKET_COUNT = 10000) );
- 声明时必须用该类型：
DECLARE @updates dbo.ProductUpdateList; - 哈希索引的
BUCKET_COUNT应 ≥ 预期唯一键数量（宁高勿低，10 倍以内可接受）
注意：它不支持 TEXT、NTEXT、XML 等大对象类型，且无法在非本机编译模块中获得最大性能收益。
容易被忽略的坑：表变量索引与执行计划缓存
普通表变量无法建索引（除主键/唯一约束隐式创建外），所以 JOIN 列没索引 = 强制嵌套循环。而内存优化表变量必须带索引（哈希或非聚集），否则报错。另一个隐形陷阱是：表变量不触发重编译，但它的“1 行假设”会让执行计划在首次调用后固化——如果某次传入 10 行，下次传入 10000 行，计划仍按 1 行估算，JOIN 方式错误。此时不如直接用带索引的临时表，或加 OPTION (RECOMPILE) 强制重编译。
真正影响并发性能的，往往不是“用了表变量”，而是是否规避了 tempdb 争用、是否误判了数据规模、是否忽略了索引强制要求——这些细节比语法选择更重要。
