Oracle表连接的奇怪问题
2009-09-11 01:05 潇湘隐者 阅读(1271) 评论(0) 编辑 收藏 举报今天在做计费报表的时候,由于粗心,拿数据的的脚本给写错了,却让我发现了一个很奇怪的问题,下面来让我介绍我发现的这个问题:数据库有表 CHARGE_REF , CLIENT_INVOICE ,CLIENT_INVHDR。其中CHARGE_REF表是保存的收费类型的数据;CLIENT_INVHDR表保存的是发票头部信息,CLIENT_INVOICE表保存的是发票的详细信息,大体如下图所示


我当时拿数据的时候的脚本大体是这样的(这里做了简化处理)
SELECT C.CDESCPT, I.CNTR, I.AMOUNT, I.CHARGE_CODE
FROM CLIENT_INVHDR H
LEFT JOIN CLIENT_INVOICE I ON I.INVOICE_NO = H.INVOICE_NO
LEFT JOIN CHARGE_REF C ON I.CHARGE_CODE = I.CHARGE_CODE
WHERE (0 = 0)
AND I.status = 'C'
AND H.INVOICE_NO = 'A09000074'
红色的部分即是我粗心写错的地方,结果当时发现这段脚本执行不正确,当时也没有发现自己的错误,很是郁闷,发现它不是和
表CHARGE_REF 左连接,而是做了自然连接。CHARGE_REF表有42种收费类型,而CLIENT_INVOICE 表INVOICE_NO 为'A09000074' 的记录刚好为15,所以查询出来的记录是630。

当时正反迷糊,以为是左连接的问题,于是改了改脚本,结果发现和上面的脚本执行结果一样。如图所示

真是纳闷,仔细检查了下代码,突然发现是LEFT JOIN CHARGE_REF C ON I.CHARGE_CODE = I.CHARGE_CODE
这里连接条件的问题,很纳闷为什么在PL/SQL里表连接条件出错的时候,也能正常执行(望高手指点一二,小弟感激不尽),而且我猜测由于这个链接条件没起作用后,它默认使用了自然连接。运行F5后发现结果如下图,使用LEFT JOIN的那段脚本执行计划和下面的大同小异
希望各位高手多多指教!

扫描上面二维码关注我
如果你真心觉得文章写得不错,而且对你有所帮助,那就不妨帮忙“推荐"一下,您的“推荐”和”打赏“将是我最大的写作动力!
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接.
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库