TABLE变量不产生日志、不参与回滚、无SCH_M锁，适合轻量单批场景；但无统计信息、无索引，大数据量或多JOIN时性能差，且作用域限于当前批处理，无法用于动态SQL或跨层共享。
TABLE变量和临时表在并发场景下的锁行为差异
TABLE变量不会产生日志记录（仅记录分配页的少量日志），也不参与事务回滚，因此不会持有 schema_modification 锁或长时间阻塞其他会话。而 #temp_table 在创建、插入、删除时可能触发 SCH_M 锁，尤其在高并发执行相同存储过程时，容易出现锁等待甚至超时。
实操建议：
- 若逻辑只涉及单次数据暂存（如中间结果过滤、循环内小集合处理），优先用
DECLARE @t TABLE(...) - 避免在事务中依赖 TABLE 变量的“回滚一致性”——它根本不会回滚，
INSERT后的数据始终存在直至批处理结束 - 注意：SQL Server 2019+ 中，TABLE 变量默认无统计信息，优化器常按 1 行估算，可能导致嵌套循环被误选；可加
OPTION (RECOMPILE)或使用CREATE STATISTICS（仅企业版）缓解
什么时候TABLE变量反而会拖慢并发性能
当数据量超过几千行、或需多次 JOIN / WHERE 过滤时，TABLE 变量缺乏索引和统计信息的缺陷会被放大，导致执行计划低效，CPU 和内存压力上升，间接降低并发吞吐。
实操建议：
- 批量插入 > 5000 行时，改用
#temp_table并显式建索引：CREATE INDEX IX ON #t(col) - 避免在 TABLE 变量上写
SELECT * FROM @t JOIN ...多次——每次 JOIN 都触发全表扫描，不如一次性导出到带索引的临时表 - 若必须用 TABLE 变量且数据量波动大，可在声明后加
/* OPTIMIZE FOR (@t UNKNOWN) */提示（SQL Server 2022+ 支持更直接的提示）
TABLE变量作用域与存储过程重入问题
TABLE 变量的作用域严格限定在当前批处理（batch）或存储过程内，无法跨 EXEC() 或动态 SQL 访问。这点常被误认为“更安全”，但实际会导致重入逻辑失败。
实操建议：
- 不要在动态 SQL 字符串里引用外部声明的 TABLE 变量——
EXEC('SELECT * FROM @t')必报错Must declare the table variable "@t" - 若需动态操作，改用临时表：
#t在同一会话的动态 SQL 中可见（前提是未在子过程中被DROP） - 多层嵌套存储过程调用时，每个层级的 TABLE 变量完全隔离，无需担心命名冲突，但也无法共享上下文数据
替代方案：表值参数（TVP）与内存优化表的适用边界
TABLE 变量本质是客户端传入的 TVP 的服务端镜像。当需要从应用层批量传参（如 C# 的 DataTable），TVP 比反复 INSERT 到临时表更高效，且复用执行计划。
实操建议：
- 定义 TVP 类型时，字段顺序、NULL 性、长度必须与客户端严格一致，否则抛错
The table-valued parameter "@p" must be declared with a type that is compatible... - 内存优化表（
MEMORY_OPTIMIZED = ON）适合超高频小数据读写，但不支持外键、CHECK 约束，且需数据库启用MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON - 别把 TVP 当万能药——单次传入 10 万行以上，网络序列化开销可能反超临时表
真正影响并发的从来不是“用不用临时对象”，而是数据生命周期是否精准匹配：该瞬时就瞬时，该复用就建索引，该跨批就换机制。TABLE 变量不是银弹，只是在“轻量、单批、无统计依赖”这个窄缝里最省心的选择。
