今天想聊清楚Oracle联表查询这件事。不管你做业务开发、写报表还是做数据分析，只要跟Oracle打交道，早晚会遇到一张表装不下所有信息的情况：订单在A表、客户在B表、明细在C表，想一次性把关联数据都取出来，就得靠联表查询。这一期是Oracle语句系列的第24期，我把联表查询和集合运算放在一起讲透，适合单表查询已经没问题、一遇到多表就思路卡壳的同学，也适合想系统梳理JOIN细节的老手。
“集合”这个词其实很妙。它既指我们把多张表放到一起处理这件事，也指Oracle里UNION、INTERSECT、MINUS这一族集合运算符。很多教程把JOIN和集合运算分开讲，我在这期里把它们放在同一个框架下，因为它们本质上都是在拿“集合”做文章：JOIN是把多张表的行横向拼起来，集合运算是把多个查询结果的行纵向合并起来。把这条主线抓住了，后面所有的语法细节都不难理解。
我会先从连接方式的底层逻辑讲起，再逐个拆解Oracle里的各类JOIN写法，包括很多老库还在用的(+)语法，然后讲集合运算，最后用几个真实业务场景把前面所有东西串起来，再加上一份联表查询的踩坑速查表。每一部分我都会给出能直接复制去执行的SQL示例，并顺带说清楚“为什么这么写”和“这么写会踩什么坑”。
1. 为什么联表查询是Oracle开发绕不开的坎
1.1 业务数据天生就是“分散”的
开始写代码之前，得先理解一个问题：为什么一张业务表不把所有字段都塞进去，非要把数据拆成多张表？我见过不少新手为此头疼，其实这是数据库设计的必然选择。
举个例子。一套最简单的订单系统，通常会有订单主表、订单明细表、客户表、商品表。订单主表记录一次下单的总体信息，比如订单号、客户编号、下单时间；订单明细表记录这次订单里每一件商品的名称、数量、单价；客户表和商品表则是维度信息，分别描述客户和商品本身。
如果把这些全塞进一张表，会发生什么？一个订单只要包含三件商品，订单主表里关于客户和下单时间的信息就要跟着重复三遍。数据量小的时候看着无所谓，数据量一上来，存储浪费、更新不一致、统计口径混乱这些问题一个接一个来。所以关系型数据库的基本设计原则就是“拆”，各表存自己该管的事，需要完整信息的时候，再通过联表查询把它们重新拼起来。
这就引出了联表查询的实际价值：它解决的问题只有一个，把分散在各表的数据按业务关系重新组合成一张表。理解了这一点，再看后面JOIN的各种写法，你就不容易迷路。
1.2 联表查询本质上是“笛卡尔积加条件过滤”
如果只记住一句话来理解联表查询，我建议记这句：两张表连接时，数据库先把所有行做笛卡尔积，再用连接条件过滤出有效组合。
笛卡尔积就是A表每一行和B表每一行都配一次对。A表有10行，B表有20行，笛卡尔积就是200行。如果不写连接条件，这200行全都会返回，这种结果几乎没有业务意义。写了连接条件，比如“订单表的客户编号等于客户表的客户编号”，就只保留两边客户编号能对上的组合。
这个逻辑看着简单，但它解释了很多实际问题。比如为什么多表连接时行数会莫名其妙变多？因为中间过程生成了大量无效组合，如果你的连接条件写得不严谨，就会漏掉一些行或者多出重复行。所以千万别觉得JOIN就是“写个ON就行了”，你写的每一个连接条件都在决定最终结果集是否准确。
从集合论的角度看，连接操作本质上就是对两个集合做一次带有条件的组合运算。Oracle在这层逻辑之上，提供了内连接、外连接、交叉连接等不同“保留策略”，我们按场景选就行了。
1.3 三类业务关系，对应三类连接写法
联表查询之所以让很多人犯难，其实不是语法难，而是没搞清楚表之间的业务关系。我踩过的坑多了之后，总结出一套最实用的分类思路。
第一类是“主表对从表”，典型如订单主表连订单明细表。一个订单对应多行明细，这是“一对多”关系。如果只想要有明细的订单，用内连接；如果要把所有订单都留下，哪怕某个订单没有明细也要保留，就用左外连接。
第二类是“事实表对维度表”，典型如订单明细连商品表、订单主表连客户表。很多明细行的商品编号指向同一个商品，这是“多对一”关系。这种场景几乎都是左外连接，因为明细行的信息不能丢。
第三类是“自引用”，典型如员工表的上级领导字段指向员工表本身的另一行，这种自连接本质上还是“多对一”，只是来源表是同一张表。
搞清楚业务关系后，选连接类型就变成了一个简单的判断：连接的结果要不要保留左表或右表中的不匹配行。要保留左表的全部行，选左外连接；要保留右表的全部行，选右外连接；两边都要保留，选全外连接；只要匹配上的，选内连接。这就是联表查询最核心的决策逻辑。
2. 五种连接方式逐个拆：JOIN不再靠背
2.1 内连接：只留两边对得上的行
内连接是联表查询里最基础的写法，也是最常见的写法。它返回的只是A表和B表中连接条件能匹配上的行，匹配不上的两边数据都会被丢弃。
SELECT o.order_id, o.order_date, c.cust_name FROM orders o JOIN customers c ON o.cust_id = c.cust_id WHERE o.order_date >= DATE '2024-01-01';这条SQL查的是2024年之后订单对应的客户信息。订单表里如果有客户编号在客户表里查不到，那这行订单就不会出现在结果里；反过来，客户表里没有任何订单的客户也不会出现。
有人会奇怪，为什么ON条件里不额外加一个“客户状态正常”之类的限制？可以加，但你要清楚ON和WHERE的区别：ON是连接条件，决定哪两行能配对；WHERE是结果过滤，决定最终结果集里保留哪些行。在内连接里写ON和WHERE结果几乎一样，但到了外连接里，两者的差别就是两种完全不同的结果，下一节我会专门讲这个坑。
内连接还有一个生活化类比：就像两个通讯录名单做核对，只有两边都能对得上号的人才出现在最终名单里。你平时写联表查询，超过六成情况用的都是它。
2.2 左外连接与右外连接：以一边为主
左外连接（LEFT OUTER JOIN）是我们日常接触最多的外连接。它的规则只有一条：左表的行无条件全部保留，右表如果能匹配上就补上对应数据，匹配不上右表位置填NULL。
还是用订单和客户举例。假如你在排查“哪些订单没有有效客户编号”，或者要保证订单数据一条不丢，就一定要用左外连接：
SELECT o.order_id, o.order_date, c.cust_name FROM orders o LEFT JOIN customers c ON o.cust_id = c.cust_id WHERE o.order_date >= DATE '2024-01-01';这条SQL和刚才内连接的差距非常直观：客户编号匹配不上的订单仍然会返回，只是客户名字段显示成NULL。在业务上，这正好对应“订单存在，但客户档案缺失”这种场景。
右外连接说到底只是把主表换到了右边，写法上对称，但实际用的很少，因为大家习惯把主表写在FROM后第一张表，也就是左边。如果你想用右外连接来表达“以某张表为主”，我建议直接调整FROM顺序改用左外连接，可读性会好很多。
接下来说ON和WHERE的区别，这是外连接里最容易出事故的地方。看这两条SQL：
-- 写法一：条件写在ON里，客户维度缺失时订单行仍保留 SELECT o.order_id, c.cust_name FROM orders o LEFT JOIN customers c ON o.cust_id = c.cust_id AND c.cust_status = 'ACTIVE'; -- 写法二：条件写在WHERE里，客户状态过滤会把订单行也带走 SELECT o.order_id, c.cust_name FROM orders o LEFT JOIN customers c ON o.cust_id = c.cust_id WHERE c.cust_status = 'ACTIVE';写法二看着和写法一在逻辑上很像，结果却可能完全不同。外连接是先连接、再过滤，WHERE条件一旦过滤掉右表的NULL行，左表对应的行也会跟着消失，外连接就退化成了内连接。很多报表数据莫名变少，排查到最后都是这个原因。
2.3 全外连接：两边都别丢
全外连接（FULL OUTER JOIN）是左右外连接的合体，双方不匹配的行都会保留，缺失的一侧填NULL。Oracle从9i开始支持它，更早的版本只能用UNION拼左右连接。
这种连接最典型的场景是对账、数据比对。比如ERP系统和WMS系统的库存表，两边各有一套SKU库存数据，我需要找出哪些SKU只在一边出现、哪些SKU两边都有但数量不一致：
SELECT e.sku, w.sku, e.qty AS erp_qty, w.qty AS wms_qty FROM erp_stock e FULL JOIN wms_stock w ON e.sku = w.sku;结果里会出现三种形态：两边都有且能对上的行，左表有但右表没有的行（右表字段为NULL），右表有但左表没有的行（左表字段为NULL）。你不需要写两遍UNION，一张SQL就把差异全部暴露出来，非常适合做系统间对账。
要注意的是，全外连接对性能的消耗通常比左右连接更大，如果数据量很大、连接条件复杂，执行前要确认连接字段上有没有索引，别拿几十万行直接做全表全外连接，会把人等崩溃。
2.4 交叉连接与自连接：特殊但实用
交叉连接（CROSS JOIN）是最容易被低估的一种连接。它不带连接条件，直接返回笛卡尔积。业务上真正需要全笛卡尔积的场景不多，比如“生成所有产品与所有区域的组合，用来铺计划”就是典型需求。
自连接则是拿同一张表自己连自己，主要用于有层级关系的数据。员工表查询领导信息是最经典的例子：
SELECT e.emp_name, m.emp_name AS mgr_name FROM employees e LEFT JOIN employees m ON e.mgr_id = m.emp_id;这里把同一张employees表别名为e和m，逻辑上当作两张不同的表来处理。左外连接保证没有领导的顶层员工也能查出来。凡是表里存在指向自身主键的外键字段，都会用到自连接。
2.5 NATURAL JOIN与USING：图省事之前先想清楚
NATURAL JOIN是Oracle提供的一种“自动连接”方式，它会拿两张表里所有同名的同类型字段自动做等值连接。写法很省事，但坑也大：一旦两张表有多个同名字段，连接条件就会变成多个字段的联合等值，经常不是你想要的。
-- 自动用所有同名字段连接，风险较大 SELECT * FROM orders o NATURAL JOIN customers c;所以我个人建议是，开发报表和业务代码时少用NATURAL JOIN，可读性和可控性都太差。USING子句相对好一些，它让你显式指定用哪个字段连接：
SELECT * FROM orders o JOIN customers c USING (cust_id);使用USING时，连接列在结果集中会合并成单列，不会出现两个cust_id。而使用ON时，两个cust_id都会出现在结果集里，你查出来的列多了，字段引用时还容易报ORA-00918列名重复错误。这一点很多人第一次用都不注意，后面我会再讲。
3. Oracle老语法(+)和分区外连接：存量库必须会
3.1 (+)语法的前世今生
如果你看过十年以上的Oracle存储过程，一定会遇到这种写法：
SELECT o.order_id, c.cust_name FROM orders o, customers c WHERE o.cust_id = c.cust_id(+);这里WHERE条件里的(+)就是Oracle传统的左外连接写法，表示把连接条件放在“缺少数据”的一侧。现在大部分新代码都写ANSI标准的LEFT JOIN了，但存量系统的存储过程、老报表、生产故障排查脚本里，这种(+)语法仍然大量存在。谁接手老项目，谁就必须能看懂它，因为改起来不一定难，但看不懂一定栽跟头。
用(+)语法有几个硬性规则。第一，它只能放在等号的一侧，放错位置连接方向就反了。第二，一旦某张表用了(+)标记，就不能再用ANSI标准的JOIN关键字混着写，很多SQL工具会直接报ORA-00933错误。第三，外连接的表中如果有自己的谓词条件，条件里不能引用(+)列，否则结果会莫名其妙地变成内连接。第四，不能在连接条件里用OR连接多个条件，也不能写IN子查询，这个老语法限制非常多。
所以我的建议是：新写的代码一律用ANSI JOIN写法，阅读老代码时把(+)就地翻译成LEFT JOIN来理解。至于哪些老代码需要动，我的判断标准很简单，能跑不动，要改先回归。
3.2 分区外连接：报表补零的利器
Oracle里还有一个外连接的特殊扩展，叫分区外连接（Partitioned Outer Join），用PARTITION BY扩展ON子句。它解决的痛点非常具体：做统计报表时，某一天没有数据，普通左连接会把这一天直接丢掉，但报表业务又要求“没销售也要显示0”。
假设有一张每日销售事实表，每天只有一个门店有销售，我要统计一周内每个门店每一天的销售情况，并要求缺失日期的销售显示为0。普通连接做不出来这个效果，因为事实表里根本没有那些行；这时候分区外连接可以这样写：
SELECT s.store_id, d.day_date, COALESCE(f.sales_amt, 0) AS sales_amt FROM stores s CROSS JOIN (SELECT DATE '2024-05-01' + ROWNUM - 1 AS day_date FROM dual CONNECT BY ROWNUM <= 7) d LEFT JOIN sales_fact f PARTITION BY (f.store_id) ON f.store_id = s.store_id AND f.day_date = d.day_date;它的作用逻辑可以理解为：先把销售事实表按门店维度切分成多个分区，再把每一天的维度行跟每个分区的门店行做外连接，这样每个门店在每一天都有对应行。这种写法在Oracle报表补零场景里几乎是标准解法，比先构造完整日历表再左连接要省事。
4. 集合运算：纵向合并查询结果
4.1 UNION和UNION ALL，性能差距肉眼可见
集合运算和JOIN最大的区别在方向上。JOIN是把多张表的列并排拼起来，行数通常是由连接条件决定；集合运算是把两个查询结果的行纵向堆在一起，列数必须一致、数据类型要一一对应。
先讲UNION和UNION ALL。它们都是把两个查询的结果合并，唯一的区别是UNION会去掉重复行，UNION ALL原样保留所有行。
-- 合并两个区域的订单号，重复的订单只保留一次 SELECT order_id FROM orders_north UNION SELECT order_id FROM orders_south;UNION会自动对结果做去重和排序，内部会执行SORT UNIQUE操作。数据量小还好，数据量几万行以上时，排序带来的额外开销就可能让查询慢好几倍。如果你确定两个查询结果不会重复，或者重复也无所谓，就一定要用UNION ALL。我在实际项目里见过一条查询从30秒优化到2秒，就只是把UNION改成了UNION ALL。
另外注意一个Oracle特有的细节：UNION会对结果做排序，展示顺序可能和你的直觉不一致。要控制顺序，在外层再套一层ORDER BY，不要依赖UNION自带的排序行为。
4.2 INTERSECT和MINUS，差集和交集一查就出来
INTERSECT是取两个结果集的交集，MINUS是取差集，也就是“左边有而右边没有”。
-- 哪些员工在薪资变动表里没有记录 SELECT emp_id FROM employees MINUS SELECT emp_id FROM salary_change;这类写法在做数据校验、对账和增量同步时特别好用。比如我把A表的数据全量同步到B表，想验证两边是否一致，就同时跑三组结果：A MINUS B、B MINUS A、A INTERSECT B。两边MINUS的结果都为空，说明数据完全一致；INTERSECT的行数等于A表的行数，说明B表没有缺失。比起写几十行嵌套JOIN，这种思路又直观又不容易错。
使用集合运算时，列数不匹配、数据类型不一致都会直接报错，例如ORA-01790。所以要确保两边SELECT出来的列顺序相同、类型兼容，这一点比JOIN更严格。
4.3 JOIN和集合运算之间的转换
有一类场景，同样的业务需求既可以用JOIN也可以用集合运算表达。例如“找出有订单的客户”，可以写成：
SELECT c.* FROM customers c JOIN orders o ON o.cust_id = c.cust_id;也可以写成：
SELECT * FROM customers WHERE cust_id IN (SELECT cust_id FROM orders);如果orders表里一个客户有多条订单，JOIN写法会产生重复行，IN写法不会。所以用JOIN表达这种需求前，要想清楚是否需要DISTINCT去重。
同样，“找出没买过东西的客户”可以用MINUS，也可以用NOT EXISTS，但我强烈建议少用NOT IN。因为一旦子查询结果里出现NULL，NOT IN会一条不返回，这个坑极其隐蔽。MINUS和NOT EXISTS对NULL的处理是安全的，推荐优先使用。
5. 三个真实场景实战：从需求到SQL一次打通
5.1 场景一：订单明细+客户信息+商品信息三表连接
实际开发里最常见的就是三张表甚至更多表连在一起。比如销售报表要展示订单号、下单时间、客户名称、商品名称、数量、单价，这个需求横跨订单主表、订单明细表、客户表和商品表。
SELECT o.order_no, o.order_date, c.cust_name, p.product_name, ol.qty, ol.price FROM orders o JOIN order_lines ol ON ol.order_id = o.order_id LEFT JOIN customers c ON c.cust_id = o.cust_id LEFT JOIN products p ON p.product_id = ol.product_id WHERE o.order_date >= DATE '2024-01-01' ORDER BY o.order_date DESC;这里我特意把订单明细用JOIN，客户和商品用LEFT JOIN。因为明细是订单的从表，如果某订单没有明细，说明数据已经异常，查不出来也好；但客户和商品属于维度数据，不能因为维度缺失把订单明细的行丢掉。
连接顺序我也建议按层级走：事实主表在前，明细其次，维度表最后。这个顺序不一定会被Oracle优化器完全遵守，但写出来的SQL逻辑清楚，后续维护也更方便。
5.2 场景二：库存对账，用FULL OUTER JOIN把差异全部露出来
业务方经常要求两套系统的数据对不上账需要排查。ERP库存表和WMS库存表按SKU做全外连接，把两边数量不一致的项找出来：
SELECT COALESCE(e.sku, w.sku) AS sku, e.qty AS erp_qty, w.qty AS wms_qty, CASE WHEN e.qty IS NULL THEN 'ONLY_WMS' WHEN w.qty IS NULL THEN 'ONLY_ERP' WHEN e.qty <> w.qty THEN 'QTY_MISMATCH' ELSE 'MATCH' END AS check_result FROM erp_stock e FULL JOIN wms_stock w ON e.sku = w.sku WHERE e.qty IS NULL OR w.qty IS NULL OR e.qty <> w.qty;结果集中只有差异数据。加上一个check_result字段，业务方一眼就能看出每条差异属于哪种类型。以前我写这种对账要用两遍UNION分别查两边独有的SKU，再查一遍两边都有但数量不一致的，现在一条FULL OUTER JOIN全搞定了。
如果想顺便确认两边完全一致的数据量，加一条INTERSECT查询做交叉验证即可，最终给老板的结论也更扎实。
5.3 场景三：销售报表补零，没销售的门店也要展示
报表需求里很常见的一种是“按天统计各门店销售额，没有销售的天也要显示0”。如果直接对销售事实表做分组统计，没有数据的天根本不会出现行，报表上就是缺一块。
我的处理思路是分两步。第一步，用CONNECT BY生成一个连续日期维度。第二步，把日期维度和门店维度做笛卡尔积，再左连接销售事实表，用NVL或COALESCE把空值补成0：
WITH date_dim AS ( SELECT DATE '2024-05-01' + LEVEL - 1 AS day_date FROM dual CONNECT BY LEVEL <= 7 ), store_dim AS ( SELECT store_id, store_name FROM stores ) SELECT d.day_date, s.store_name, COALESCE(SUM(f.sales_amt), 0) AS day_sales FROM date_dim d CROSS JOIN store_dim s LEFT JOIN sales_fact f ON f.store_id = s.store_id AND f.day_date = d.day_date GROUP BY d.day_date, s.store_name ORDER BY d.day_date, s.store_name;这里最关键的一点是：销售事实表的连接条件必须同时包含门店和日期两个维度，只连接其中一个会造成结果行数爆炸。COALESCE补零后，报表里的缺失日期就全部有值了。用WITH子句把日期维度和门店维度分开管理，后续要改成月份维度也只动一个地方。
6. 联表查询的踩坑日志与性能调优
6.1 ORA-00918和ORA-00904：列名冲突和无效标识符
联表查询最常见的报错之一就是ORA-00918列名重复。两个表里都有同名字段，比如订单表和客户表都有cust_id，如果你在SELECT里直接写cust_id而不加表别名，数据库就不知道你说的是哪个。解决方式很简单：
SELECT o.cust_id, c.cust_name FROM orders o JOIN customers c ON o.cust_id = c.cust_id;凡是多表查询，我建议一律给每张表加别名，SELECT里的每个字段都用“别名.字段名”形式，别偷懒只写字段名。不是SQL跑不出来才需要，而是为了后续可维护性。我自己接手过很多几十行没写别名的存储过程，改错一个字段名排查一下午，非常痛苦。
ORA-00904无效标识符则常见于两种情况：一是字段名打错或大小写不匹配，二是SELECT里的别名在WHERE中使用。要知道WHERE子句的执行顺序早于SELECT的别名生成，所以WHERE里不能用SELECT定义的别名，需要用到外层包一层子查询或直接重复写表达式。
6.2 连接字段没有索引，执行计划直接把你卡死
联表查询的性能问题，有一大半出在连接字段没有索引。内连接时数据库要拿A表的每一行去B表找匹配行，如果B表的连接字段没有索引，就相当于每读一行都要扫一遍整张B表，这种操作的代价是灾难性的。
拿订单表和客户表连接举例，等值连接用到客户表cust_id时，客户表的cust_id如果是主键，天然有唯一索引；如果不是，就要确认是否有普通索引：
CREATE INDEX idx_customers_cust_id ON customers(cust_id);连接字段能建索引尽量建索引，尤其是频繁用于ON条件、被驱动表一侧的字段。Oracle优化器选择嵌套循环连接时，被驱动表的连接字段有没有索引，直接决定SQL要跑几十毫秒还是几十秒。索引不一定都能命中，但这些基础动作没做，后面优化再多都是空谈。
6.3 小结果集驱动大结果集，连接顺序真的有讲究
Oracle优化器通常能根据统计信息自动选择合理的连接顺序，不用我们手工干预。但有一种场景需要人为介入：数据量极度不均衡时，优化器判断失误，小表被当成大表来驱动，整个执行计划就崩了。
所谓“小表驱动大表”，就是用数据量小的那个结果集作为外层循环去匹配数据量大的表。比如5000万行的订单明细连接10000个客户，正确策略是以客户表作为驱动，每条客户记录到订单明细里去找订单；如果反过来，拿订单明细循环去匹配客户，几千万次的索引查找也让人心疼。
判断当前SQL连接顺序是否合理，看执行计划里的NESTED LOOPS和HASH JOIN就能知道大概。HASH JOIN适合两张大表等值连接，NESTED LOOP适合一边数据量很小的情况。如果发现优化器选了奇怪的路径，可以先更新统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'ORDERS'); EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'CUSTOMERS');统计信息准确后，优化器的判断通常都会回归正轨。不到万不得已别加提示(/*+ LEADING */)硬改执行计划，我见过很多硬改计划后来数据量变化又变差的例子。
6.4 结果行数莫名变多：一对多连接后的膨胀
一个非常隐蔽的坑是，连接后再聚合导致数值翻倍。比如订单明细和发货记录连接，一个订单可能有多次发货记录，连接结果行数自然成倍膨胀。如果此时对订单金额做SUM，会把金额重复计算。
这种问题的规范解法是先聚合再连接。先把发货记录按订单聚合成一次一行，再和订单明细做连接。如果业务上确实需要先连接再聚合，也要确认聚合函数里用的是不是DISTINCT字段。
| 现象 | 常见原因 | 处理方式 |
|---|---|---|
| 结果行数远大于主表行数 | 一对多连接导致笛卡尔膨胀 | 检查连接条件是否遗漏维度字段；先聚合再连接 |
| 外连接变成了内连接效果 | ON条件用错或WHERE里过滤了右表NULL行 | 右表过滤条件移到ON子句，或改用子查询 |
| SUM金额重复 | 一对多连接后聚合 | 先按子表聚合，再连接主表 |
| 查询慢到怀疑人生 | 连接字段无索引或统计信息过期 | 建索引、刷新统计信息、查看执行计划 |
| ORA-00918列名重复 | 多表同名字段未加别名 | SELECT字段全部加表别名限定 |
| ORA-01790数据类型不一致 | UNION等集合运算两侧表达式类型不匹配 | 对齐两边列顺序和数据类型 |
排查联表查询问题，我的固定套路是先跑单表，确认各表单独的行数都符合预期，再逐步加JOIN，每次加一张表都看一眼结果行数变化。这种方式能最快定位是哪一步连接出了问题，而不是等整条SQL全写完再抓瞎。
6.5 汇总经验：联表查询的日常习惯
最后分享我自己在实际项目里的几个固定习惯。第一，所有SQL无论大小，都给表加别名，字段全部带别名前缀。第二，连接顺序按“事实表—明细表—维度表”的层级来写，逻辑清晰，也方便后续加表。第三，能写LEFT JOIN就不写RIGHT JOIN，统一主表在左的习惯，别人接手也省心。第四，集合运算前先确认列数和类型，两边格式不一致时先用函数转换，比如TO_CHAR、TO_NUMBER，别让Oracle替你猜。
踩过几次坑之后，我最大的体会是：联表查询出错，很少是某条语法不会写，往往是业务关系没理清、连接条件没想透。把数据关系画出来，再对照内连接、外连接、集合运算的语义去选，大部分问题都能迎刃而解。如果下次再遇到莫名其妙的重复行，先做一步笛卡尔积估算，看看中间组合数合不合理，问题基本就暴露了。
