话说回来，

从Oracle迁到金仓。首月最大的坑

一、上线当天的报表数据对不上

去年帮一个客户完成Oracle到金仓的迁移，折腾了两个月。终于到了上线那天业务方下午三点打

我立即登录数据库，抽取那条报表SQL：

SELECT o.order_id。o.amount,r.refund_amount
FROM orders o
LEFT JOIN refunds r ON o.order_id = r.order_id
WHERE r.status = 1;

Oracle返回1280行。而金仓只返回1123行，缺少了157条。

我检查语法没有问题。却在执行计划里看到一个普通的Hash Join，没有外连接标识。原来金仓调整器把LEFT JOIN转成了INNER JOIN。

在Oracle里这种写法保留了左表无匹配右表的行；而金仓在WHERE里看到r.status = 1后把NULL行过滤掉，等价于INNER JOIN。

二、使用者痛点：报表不准、上线风险、性能波动

• 报表数据不一致：
• 上线后出现Bug：
• 性能下降或提高失衡：

三、常见导致外连接被消除的写法

旧式Oracle语法

SELECT *
FROM t1,t2
WHERE t1.id = t2.id
AND t2.status = 1;

+ WHERE 条件混用

CREATE VIEW v_orders AS
SELECT *
FROM orders LEFT JOIN refunds
ON orders.id = refunds.order_id;-- 查询时
SELECT *
FROM v_orders
WHERE status = 1;

这些写法在Oracle里是合法且常见。但在金仓中往往被调整器视为可转为INNER JOIN，从而丢失左连接特性。

四、排查流程

1. 查看执行计划：EXPLAIN PLAN FOR ...;若计划里没有 Left Join,很可能已被消掉。
2. 检查右表条件：
3. 验证数据量：
4. Scripting 自动化检测：

五、稳妥 规则

改为标准 LEFT JOIN 并将条件放 ON 中

-- 原写法
LEFT JOIN refunds r ON o.id = r.order_id
WHERE r.status = 1;
-- 推荐
LEFT JOIN refunds r
ON o.id = r.order_id
AND r.status = 1;

替换为标准 LEFT JOIN 并保持逻辑完整

示例

SELECT *
FROM t1 LEFT JOIN t2
ON t1.id = t2.id AND t2.status = 1;

在视图中避免外部过滤

-- 原视图定义
CREATE VIEW v_orders AS
SELECT * FROM orders LEFT JOIN refunds ON orders.id=refunds.order_id;-- 查询时不要再加右表条件到 WHERE 中，而是放进 ON 或使用 INNER JOIN 如需筛选。SELECT * FROM v_orders WHERE status=1;-- 不建议
-- 推荐
查询的观点是，SELECT * FROM v_orders AS vo
JOIN refunds AS rf ON vo.order_id=rf.order_id AND rf.status=1;

用 INNER JOIN 明确业务需求

If 保留左表所有行不是业务要求。可以直接改为 INNER JOIN，以避免误删数据，并获得更优执行计划。

六、为什么金仓要这么做？

• Avoiding unnecessary NULL rows:
• A mamatical equivalence check:
• Pitfall:

七、经验

• 先扫全局外连接：  在迁移前梳理所有外连接。把含有右表条件的地方全部提前修改，避免上线后才发现问题。
• 边界数据核对：  拿几条左侧无匹配右侧、有匹配及双侧都有记录进行单独跑检验，对比数量是否一致。至少每类取数十条做验证，
• 养成查看执行计划习惯：  任何涉及 LEFT/RIGHT CONNECT 的 SQL 都先跑 EXPLAIN 查看是否真的保留了外连接标记。看不到 Left 标识就要及时调整或检查逻辑是否安全变成 INNER.
• 日志监控 & 报告自动化：  编写脚本定期扫描代码库。将潜在消除点输出报告，让团队提前知晓并修复。也可以集成到 CI/CD 流水线中，防止新提交引入旧坑。
• 文档化规范：  把“将右表条件放入 ON”还有“必要时改用 INNER”列入开发规范，在代码评审阶段强制检查。按理说，这样即使新人上手也能遵循常用方法减少错误率。