写 SQL 的人默认自己在描述“做什么”。但很少有人认真想过从语句提交到结果返回之间，那条语句被改成了什么样子。

绝大多数情况下不需要想。直到某天执行计划变了、迁移换了内核、或者一条依赖求值顺序的语句开始时好时坏，才会发现自己一直站在一层假设上面：以为写下去的东西就是执行的东西。

一、“等价”只保证结果集。不保证过程

查询变换里的“等价”，指的是变换前后返回的结果集等价。多重集意义上的等价，行数和内容一致。

没被包含在这个承诺里的东西比想象中多：每个表达式被求值几次条件按什么顺序检查。某个函数会不会因为短路而完全不执行，运行时错误在哪个时刻抛出，甚至结果的返回顺序——只要没写 ORDER BY，顺序从来不在保证范围内。

SQL Server 上有一个流传很广的例子：

SELECT CAST FROM t WHERE ISNUMERIC =;

按书写顺序理解。先过滤出能转成数字的行，再做转换，逻辑无懈可击。实际执行时可能报转换失败，因为投影列的计算标量可以被调整器调度到过滤之前。而结果集在没有错误发生的前提下是等价的——调整器的推理里不包含“这次转换会抛错”这件事。

这条规则解释了很多看起来毫无道理的现象。把有副作用的函数放进 WHERE、靠条件顺序控制执行流程、指望某个函数每行只算一次这些写法之所以不安全。并不是因为哪个数据库实现得不好，而是它们要求的保证从一开始就不在契约里。

理解了这一点。再看下面这些变换，就知道该怕什么。

二、等价变换的几个主要家族

各家的变换清单加起来有几十条。但真正需要理解的是不是清单，而是每条变换成立的前提。前提被破坏时它不做，前提被误判时它出错。

常量折叠与表达式预处理

编译期能算出来的表达式提前算掉，例如 WHERE a = + 变成 WHERE a = 。不过，这里门槛就是函数易变性标记。以 KES 为例分三档：IMMUTABLE 的函数可以在生成计划时直接求值；STABLE 的可以在一条语句内只算一次；VOLATILE 的必须每行都算。声明错了不会报错，只会让调整器在错误的前提下做决策——把一个读表的函数标成 IMMUTABLE。结果被折叠成常量，问题要等到某次计划变化才浮出来。

PREDICATE 下推与等价类传递

t1.a = t2.a AND t1.a = 可以推出 t2.a = ,这个新条件让 t2 也能用上索引。调整器通常把这件事做成一套显式等价类机制，把所有已知相等表达式收进同一个集合，用来派生新的过滤条件。也用来推导排序键——如果已知 t1.a = t2.a,那么按 t1.a 有序的数据流也按 t2.a 有序，上层排序节点就可以省掉。同一套结构服务两个目的，是调整器设计里比较漂亮的一种思路。

下推有明确边界：聚合之上的条件不能随便推到聚合之下；外连接可空侧条件不能推过连接；含 VOLATILE 函数条件不能跨节点移动。这些边界在实现里都是显式检查，不是靠运气。

外连接化简

示例：

SELECT * FROM orders o LEFT JOIN payments p ON p.order_id = o.id WHERE p.status = 'PAID';

写的人以为自己在做外连接，但因为 WHERE 里有对可空侧严格条件。所有补 NULL 的行都会被过滤掉，这个 LEFT JOIN 与 INNER JOIN 完全等价。调整器会做化简，在执行计划里直接显示 Inner Join。变换本身没错，却误导我认为保留左表全集。条件应该写在 ON 上还是 WHERE 上？语义完全不同，这不是风格问题。

子查询展开与去关联

典型场景：

• IN / EXISTS 子查询通常转成半连接或 NOT EXISTS 转成反连接；转换后能参与连接顺序和算法选择，对性能差距可能相差几个数量级。
• NOT IN 语义难题：a NOT IN 在 b 可能为 NULL 时不等价于反连接：只要子查询出现 NULL。整个结果就是空集，而反连接会照常返回行。从各家分两派来看，保守派除非能证明列不可空，否则不做转换；Oracle 从 11g 起支持 null-aware anti join。让反连接自行处理 NULL 语义，实现转化后性能保持稳定。这是典型取舍之一：实现简单 vs 使用者友好 vs 执行器复杂度提高。

连接消除

规则：

• LEFT JOIN 可消除，当内侧唯一性证明且外部未引用其列时；内连消除更强，需要基于外键约束证明才能删除。按理说，

A 关键约束不仅是数据校验工具。也是调整器证明材料来源， NOT NULL 决定 NOT IN 能否转为反连；唯一索引决定是否能消除连接；外键决定行数估算准确度，在迁移过程中，为导数方便临时去掉约束。会永久失去这些推理依据，对性能产生深远影响。

三、条件执行调度：在哪层算谁先算

条件放在哪里执行，比它写在哪里关键得多。一条过滤最终可能落到三个位置：

• 作为索引访问条件。直接决定扫描起止范围，可减少 I/O;按理说，
• 作为索引层过滤。 在索引项上判断，可减少回表次数;
• 回表后再数据行过滤。此时 I/O 已经发生，只是少往上层传几行。三者成本差着量级.

四、四条取舍轴

"变换是规则驱动还是代价驱动"

• Dora Style : 许多调整器将变换做成启发式规则。只要满足即可，无需评估实际快慢。这种方式规划阶段快，对高并发短查询负载友好。但缺点是可能出现“变换导致更慢”的情况.
• Cassandra Style : Oracle 从10g 起提供.
• Liberal Aggression: 如聚合提前到连之前，将聚合提前至联接之前，以大幅减少参与连的数据量—Oracle 支持此类 而其他数据库尚未实现.
• Tuning Trade‑offs: 激进方案让使用者无需了解复杂细节即可获得优质计划。但若底层实现缺陷则风险较高.

"允许人工干预程度"

• No Hint Policy: 认为提示掩盖真实问题，引入偏差和过期风险，应留粗粒度开关 .
• Total Hint Support: Oracle 和 SQL Server 提供完整提示程序，让使用者掌控最细粒度 .
• KES 特殊策略:* 内置 HINT 能力覆盖多维度。说起来，计划，新计划需证明更优方可启用;其实，
• * SQL Server Query Store 强制固定并自动纠正异常计划;
• * 国产数据库这几年主要投入此方向，以提高生产程序整体可靠性—略慢但稳定往往比平均更快但偶尔翻车更具价值.

",

"