能，但仅限于同一执行上下文内显式赋值并引用；否则每次仍重新计算，且可能因打断优化器估算而降低性能。
SQL Server 存储过程中局部变量能缓存计算结果吗？
能，但仅限于「同一执行上下文内」重复使用同一表达式时有效。SQL Server 不会自动帮你“记忆”变量值跨语句复用，必须显式赋值 + 显式引用，否则每次 SELECT 或 SET 都会重新求值。
常见错误现象：@total = (SELECT SUM(amount) FROM orders WHERE status = 'shipped') 写在开头，后面却仍写 WHERE total > (SELECT SUM(amount) FROM orders WHERE status = 'shipped') —— 这里根本没用上变量，子查询照常执行两次。
- 务必把计算结果赋给变量后，后续逻辑全部引用
@total，而不是再写一遍子查询 - 变量类型要足够容纳结果（比如
SUM可能溢出INT，优先用BIGINT或DECIMAL） - 如果计算依赖输入参数（如
@year），确保变量在参数被修改前完成赋值
什么时候用局部变量反而拖慢性能？
当变量用于「打断查询优化器估算」时，尤其是出现在 WHERE 条件中且值不确定（如来自另一表的聚合），SQL Server 往往放弃使用索引，退化为扫描。
典型场景：先算出 @threshold = SELECT AVG(score) FROM exams，再执行 SELECT * FROM students WHERE score > @threshold。优化器不知道 @threshold 具体值，无法选择合适索引或估算行数，可能选错执行计划。
- 若阈值稳定（如固定数值、配置表单条记录），改用
DECLARE @threshold DECIMAL(5,2) = 75.5，让编译器“看得到”值 - 若必须动态计算，考虑用 CTE 或内联视图替代变量，例如
WITH cfg AS (SELECT AVG(score) t FROM exams) SELECT s.* FROM students s, cfg c WHERE s.score > c.t - 对关键路径上的变量赋值，建议加
OPTION (RECOMPILE)强制重编译，避免参数敏感型执行计划被缓存复用
PostgreSQL / MySQL 和 SQL Server 的变量行为差异
不是所有数据库都支持“声明即赋值”或“变量作用域=批处理”。SQL Server 的 DECLARE+SET/SELECT 是最宽松的；PostgreSQL 要求变量只能在 PL/pgSQL 块内用 :=；MySQL 的用户变量 @var 虽灵活，但行为不稳定——尤其在连接复用、并行查询下可能被覆盖或延迟赋值。
- SQL Server：变量作用域是整个存储过程，赋值后可跨
IF、WHILE使用 - PostgreSQL：必须包在
BEGIN ... END中，且不能在纯 SQL 语句中直接赋值（如SELECT ... INTO是另一种机制） - MySQL：避免在同一个语句中既赋值又读取（如
SELECT @x := @x + 1, @x），顺序不保证；高并发下慎用@变量缓存中间结果
缓存计算值时最容易漏掉的边界情况
空结果集、NULL、类型隐式转换这三类问题，会让变量持有一个“看似正常实则失效”的值，后续逻辑静默出错。
例如：SELECT @count = COUNT(*) FROM users WHERE role = 'admin' 没问题；但 SELECT @max_id = MAX(id) FROM users WHERE active = 1 在无匹配行时，@max_id 保持原值（可能是上次残留的旧值），而不是变成 NULL —— 这点和多数人直觉相反。
- 对聚合函数结果赋值，始终显式处理 NULL：
SELECT @max_id = ISNULL(MAX(id), 0) FROM ... - 避免依赖变量“未赋值即为 NULL”，声明后立即初始化：
DECLARE @retry_count INT = 0 - 跨多语句复用变量前，确认上一句是否真的执行了（比如被
IF条件跳过），必要时加PRINT或日志表记录实际值
变量不是银弹，它只解决“同一过程内避免重复计算”的问题；一旦涉及跨批次、跨连接、或需要统计信息驱动优化，就得换思路——比如物化中间结果到临时表，或者重构为内联表值函数。
