子查询在存储过程中不自动缓存，每次执行均重算；应优先使用临时表显式缓存中间结果，并建索引优化后续访问，cte仅是语法糖不保证物化。
子查询在存储过程中不自动缓存，重复执行等于重复查表
SQL Server、MySQL 或 PostgreSQL 的存储过程里，写两次一样的 SELECT ... FROM (subquery) AS t，数据库不会帮你“记住”第一次的结果。每次遇到就重跑一遍——哪怕子查询耗时、扫描上百万行、还带聚合或 JOIN。这不是 bug，是标准行为：SQL 引擎按需求值，没有隐式中间结果生命周期管理。
实操建议：
- 用
WITH（CTE）把子查询提成命名临时结果，但注意：CTE 在多数引擎中只是语法糖，不保证物化（PostgreSQL 12+ 加MATERIALIZED才强制；SQL Server 需配合OPTION (RECOMPILE)和统计信息才可能复用） - 真要缓存，得显式落地：用
CREATE TABLE #temp（SQL Server）或CREATE TEMPORARY TABLE（MySQL/PG），再INSERT INTO ... SELECT一次，后续全查这个临时表 - 别在循环体里反复调用含子查询的视图或表值函数——每次调用都重算，不是“查缓存”
临时表比 CTE 更可靠地复用中间结果
当你需要多次引用同一组计算结果（比如用户标签聚合、订单状态快照），WITH 看起来干净，但执行计划里常被展开成多次子查询。而临时表是物理存在的，插入后数据就在内存或 tempdb 里，后续 SELECT 直接走索引或顺序扫描，开销可控。
实操建议：
- SQL Server：优先用
#temp_table，建好后立刻加索引（CREATE INDEX IX ON #temp(col)），尤其对后续 JOIN 或 WHERE 过滤的字段 - MySQL：用
CREATE TEMPORARY TABLE tmp AS SELECT ...，注意它不支持外键和全文索引，但能用INDEX语句显式建索引 - PostgreSQL：用
CREATE TEMP TABLE tmp AS SELECT ...，默认不记录 WAL，速度快；如需排序/JOIN 性能，手动CREATE INDEX ON tmp(col) - 别省那句
DROP TABLE #temp（SQL Server）或依赖会话结束自动清理——长事务或连接池复用下，残留临时表可能引发冲突
WHERE 条件下推进子查询反而破坏缓存机会
有人为了“提前过滤”把外层 WHERE 拆进子查询里，比如把 SELECT * FROM (SELECT u.id, u.name FROM users u) t WHERE t.id IN (1,2,3) 改成 SELECT * FROM (SELECT u.id, u.name FROM users u WHERE u.id IN (1,2,3)) t。这看似减少数据量，但会让子查询失去通用性——一旦外层条件变，就得重写整个子查询，没法复用临时表或预计算结果。
实操建议：
- 先用临时表存宽泛结果（如当天所有订单），再在外层用
WHERE精确筛选——这样临时表可被多个分支逻辑共用 - 如果子查询本身带参数（如
@date），确保参数值稳定；否则每次传不同值，缓存无意义 - 避免在子查询里用
GETDATE()、NOW()这类运行时函数——它们让子查询结果不可预测，优化器不敢复用
EXEC sp_executesql 动态拼接时，子查询缓存完全失效
用 sp_executesql 拼接 SQL 字符串时，哪怕子查询内容完全一样，只要字符串地址或参数绑定方式稍有差异（比如空格数、参数名大小写），SQL Server 就视为全新语句，不共享执行计划，更别说中间结果了。这是硬限制，不是配置问题。
实操建议：
- 能不用动态 SQL 就不用；必须用时，把子查询逻辑抽成视图或内联表值函数（ITVF），然后在动态语句里只调用它，让优化器有机会复用底层计划
- 拼接前统一格式：去掉多余空格、固定参数占位符名（始终用
@p1而非@param1）、避免字符串插值，改用参数化传入 - 检查执行计划里的
CachePlan属性是否为true，以及UseCounts是否随调用递增——这是最直接的缓存生效证据
真正难的不是“怎么写”，而是判断哪部分子查询值得缓存：数据变动频率、下游使用次数、计算成本三者得一起看。一个每秒跑十次但只查 10 行的子查询，缓存收益几乎为零；而一天跑一次但扫三千万行的，值得拆成夜间作业预计算。
