SQL CTE是否应存储常量值？求SQL从业者评析该实践优劣

这种把常量塞进CTE再通过1=1关联的写法，在SQL圈子里不算主流，但确实有其存在的价值，下面从实际使用的角度拆解它的优缺点：

优点 #

• 减少硬编码重复：如果SQL里多处用到同一个常量（比如示例里的'myValue'），用CTE统一维护后，改值只需要动一处，避免了漏改多份字面量的风险——这和.NET里把重复值抽成const字段的思路完全一致。
• 提升代码可读性：给常量起一个有意义的别名（比如myValue），比直接扔一串字符串字面量更清晰，其他开发者看代码时能快速get到这个值的用途，不用猜字符串代表什么业务含义。
• 部分场景下的执行计划优化：像SQL Server这类数据库，会把CTE里的单一行常量视为固定值，生成执行计划时可能会做针对性优化，尤其是当常量用于过滤条件时，执行计划的稳定性比重复写字面量更好。

缺点 #

• 冗余的关联逻辑：通过INNER JOIN myConstants mc ON 1=1做笛卡尔积关联，虽然大多数数据库优化器能识别这是个单一行的常量表，不会产生实际性能损耗，但在复杂查询里会让执行计划的逻辑变得啰嗦，新手看的时候容易困惑。
• 有更简洁的替代方案：简单场景下，用变量（DECLARE @myValue VARCHAR(100) = 'myValue'）或者直接在SELECT里定义常量列，写法比CTE更轻便。比如：

  DECLARE @myValue VARCHAR(100) = 'myValue';
  
  SELECT
      (SELECT .......
       WHERE x.myValue = @myValue
      ) AS mySubQuery
  FROM 
  .......
  

• 视图中的局限性：如果是在视图里用这种写法（因为视图不能定义变量），CTE是可行的替代，但当常量需要频繁修改时，视图的维护成本会比「存储过程+变量」的组合更高。

内容的提问来源于stack exchange，提问作者c0sm1cP1rate