表变量仅适合≤100行场景，因SQL Server优化器固定按5行估算基数，数据量超限易致执行计划错误（如该用Hash Match却选Nested Loop），引发逻辑读与CPU耗时剧增；临时表#t支持统计信息、索引及跨批访问，是复杂查询与嵌套过程的可靠选择。
表变量不是万能加速器，数据量超100行就该换临时表；盲目替换反而让执行计划选错连接方式，查询从毫秒级拖到秒级。
表变量只适合≤100行的中间结果
SQL Server优化器对@table_var固定按5行估算基数，哪怕你INSERT了800行，后续JOIN仍可能走嵌套循环（Nested Loop），而本该用哈希匹配（Hash Match）的地方被跳过。实测：1000行数据用@t做JOIN主表，逻辑读飙升3倍，CPU耗时翻4倍。
- ✅ 适用场景：收集一批ID后批量UPDATE、函数内聚合小范围状态、单次计算后直接RETURN
- ❌ 不适用：需要GROUP BY后再WHERE过滤、JOIN大表前先聚合、中间结果被多个独立语句引用
- ⚠️ 注意：
SELECT * INTO #t比INSERT INTO @t SELECT快得多——后者不触发重编译，优化器看不到真实行数
临时表#t在哪些地方不可替代
#TempTable支持统计信息更新、索引、跨批访问，而@table_var完全不支持。一旦存储过程里有EXEC或sp_executesql，外层声明的@t在内层根本不可见，会报“对象名无效”。
- 必须用
#t：嵌套存储过程间传递中间集、多次JOIN/GROUP BY/ORDER BY复用同一结果、需要UPDATE STATISTICS #t手动修正基数 - 索引很关键：没索引的
#t在WHERE或JOIN时极易退化为全表扫描；至少加一个非聚集索引，比如CREATE INDEX ix_id ON #t(id) - 字段名含空格？
SELECT * INTO #t会失败，必须显式写SELECT [user name] AS [user name]
内存优化表变量是小数据量的进阶选项
SQL Server 2014+ 或 Azure SQL 可用，但必须分两步：CREATE TYPE my_type AS TABLE + DECLARE @t my_type。它不走tempdb、无I/O、不写日志，但要求至少一个索引——哈希索引桶数建议设为预期唯一键数的1–2倍。
- ✅ 适合：≤100行、高频读写、并发高、tempdb争用明显
- ❌ 不适合：运行时动态建类型（部署阶段就得创建好）、字段含
SQL_VARIANT或自定义类型（易隐式转换失败） - ⚠️ 真正容易被忽略：字段名含空格时，即使内存优化也一样解析失败；调试时漏掉
DROP TABLE IF EXISTS #t，下次执行直接卡在“对象已存在”
最常被绕开的点是：你以为在用内存，其实表变量早因数据量上涨被刷到tempdb磁盘上；而临时表哪怕慢，至少基数准确、索引可控。别迷信“变量=内存”，先看执行计划里的Actual Rows和Estimated Rows是否一致。
