SQL 语法全兼容。却仍然出现数据不一致——国产化迁移最常见的九大隐患

使用者痛点：迁移后SQL报“执行成功”，但业务数据对不上；少了几行、多了几行或某列数值偏差。查询语法、字符集、时区、连接池都检查过却找不到根源。说起来，调试耗时长、定位困难。往往要同时弄清楚SQL语义标准、调整器行为还有不同数据库之间的差异。

一、九个容易出问题的 SQL 逻辑坑概览

迥异？" src="/uploads/images/116.jpg"/>

• A 类：调整器行为差异
  • A1 外连接消除
  • A2 谓词下推的边界差异
  • A3 子查询解嵌套引起的语义微变
• B 类：SQL 语义标准差异
  • B1 NULL 与空串等价
  • B2 三值逻辑短路差异
  • B3 排序中的 NULL 位置
• C 类：函数与表达式行为差异
  • C1 WHERE 里函数副作用与执行顺序
  • C2 字符串与数字的隐式类型转换
  • C3 日期时间与时区解析差异

下面将逐一展开。每类都配有案例、原因分析还有在金仓 KES 中的表现和 方案，帮助你直接把它们当作避坑手册使用。

A 类：调整器行为差异

A1 外连接消除

表现：带 LEFT/RIGHT JOIN 的查询迁到 KES 后结果集显著减少。

原因：KES 调整器检测到 WHERE 条件对可空侧列进行拒绝 NULL 的过滤，误判外连接等价于内连接并自动

踩坑案例：

-- 意图：所有使用者。附带展示已完成订单信息
SELECT u.user_id,o.order_amount
FROM t_user u
LEFT JOIN t_order o ON u.user_id = o.user_id
WHERE o.order_status = 'FINISHED';

实际得到的是“只有有 FINISHED 订单的使用者”。

再看方案，将过滤条件移动到 ON 子句：

SELECT u.user_id。o.order_amount
FROM t_user u
LEFT JOIN t_order o
ON u.user_id = o.user_id
AND o.order_status = 'FINISHED';

KES 兼容特点：KES 调整器遵循 ANSI/ISO 标准，可通过 EXPLAIN 明确看到 JOIN 节点是否被 为内连接。

A2 谓词下推的边界差异

表现：子查询/视图中的过滤条件被下推导致结果不一致。怎么说呢，

原因：不同数据库对可下推条件的判定规则不同。尤其涉及 LIMIT、ORDER BY、DISTINCT 或聚合时更易产生歧义。

-- 意图：查询前 N 条订单里状态为 FINISHED 的记录
SELECT *
FROM (
SELECT *
FROM t_order
ORDER BY create_time DESC
LIMIT 1000
) sub
WHERE sub.order_status = 'FINISHED';

KES 调整器可能把 `WHERE` 条件提前到子查询内部。从而先过滤 FINISHED 再取前 N 条，结果完全不同。

说到方案，使用 CTE 并强制物化防止下推：

WITH sub AS MATERIALIZED (
SELECT *
FROM t_order
ORDER BY create_time DESC
LIMIT 1000
)
SELECT *
FROM sub
WHERE order_status = 'FINISHED';

KES 兼容特点：KES 完全支持 CTE 物化，是保证语义不走样的可靠手段。

A3 子查询解嵌套

表现：`EXISTS / IN / ANY` 子查询在含 NULL 时产生意外空集或额外行。

原因：KES 调整器将子查询转为 semi‑join 或 anti‑join，提高性能。但若子查询返回 NULL，`IN`/`NOT IN` 的三值逻辑会导致意料之外的结果。

-- 查询没有关联合同的客户
SELECT *
FROM t_customer
WHERE customer_id NOT IN;

`t_contract.customer_id` 中若出现 NULL，整个查询会返回空集。

至于方案，

-- 使用 NOT EXISTS
SELECT *
FROM t_customer c
WHERE NOT EXISTS (
SELECT 1 FROM t_contract ct WHERE ct.customer_id = c.customer_id
);
-- 或者使用 LEFT JOIN + IS NULL
SELECT c.*
FROM t_customer c
LEFT JOIN t_contract ct ON ct.customer_id = c.customer_id
WHERE ct.customer_id IS NULL;

KES 兼容特点：KES 对 `NOT EXISTS` 的实现既符合标准又更高效，推荐在迁移中统一使用此写法。

B 类：SQL 语义标准差异

B1 NULL 与空串等价问题

表现：`WHERE col = ''` 在 Oracle 返回 NULL 行。而在 KES 返回真正空串行，两者结果不同。

原因：KES 按 SQL 标准把空串视作长度为0的普通字符串；Oracle 将空串视作 NULL。

-- Oracle 原意：查询 remark 为“空”的记录
SELECT * FROM t_log WHERE remark = '';-- Oracle 实际返回 remark 为 NULL 的记录
-- KES 则只返回长度为0的空串记录

SELECT * FROM t_log WHERE remark IS NULL;怎么说呢，-- 同时想匹配空串和 NULL：
SELECT * FROM t_log WHERE COALESCE = '';

KES 兼容特点：KES 提供会话或库级别参数模拟 Oracle 空串=NULL 行为，但长期建议 为标准 `IS NULL`/`COALESCE` 写法。不过，

B2 三值逻辑短路差异

表现：`AND/OR` 中混入 NULL 时不同数据库对副作用 UDF 的求值顺序不同。导致结果或性能波动，

三值逻辑真值表
true AND unknown	= unknown
false AND unknown	= false
true OR unknown	= true
false OR unknown	unknown

 SELECT * FROM t
WHERE t.col1 = 'A'
AND expensive_udf> 10;

如果 t.col1 为 NULL，则 t.col1='A' 为 Unknown。话说回来，部分数据库会继续计算 expensive_udf而其他则直接短路返回 False。

建议 : 避免在 WHERE 中使用有副作用的 UDF；若必须使用，只保留 pure 函数并标记属性。

KES 特性 : 支持函数属性 STRICT,IMMUTABLE。STABLE,VOLATILE,LEAKPROOF帮助调整器决定是否可以下推或短路求值。

B3 排序中的 NULL 位置信息不统一

表现 : 一样 ORDER BY col ASC 在 MySQL、Oracle 与 KES 中对 Null 的排序顺序各不相同，导致分页或 TopN 数据错位。

• Oracle : ASC → Null 最终;DESC → Null 最前。
• PostgreSQL/KES : ASC → Null 最终;DESC → Null 最前。
• MySQL : ASC → Null 最前;DESC → Null 最终。

踩坑案例 :

sql -- 按 priority 升序取前 N 条 SELECT * FROM t_task ORDER BY priority ASC LIMIT 100;

若表中存在 Null。在 MySQL 会先返回大量 Null 行，而 KES 则返回实际最小非 Null 值行。老实说，

方案 :

sql SELECT * FROM t_task ORDER BY priority ASC NULLS LAST LIMIT 100;

从或者来看，

KES 支持 : 完整实现 ANSI 标准 NULLS FIRST / NULLS LAST 与 COALESCE 用法。

C 类：函数与表达式行为差异

C1 WHERE 中函数副作用与执行顺序

---