oracle数据库 笛卡尔积,这条为什么会产生笛卡尔积，谢谢！！

最新推荐文章于 2024-03-27 06:23:07 发布
最新推荐文章于 2024-03-27 06:23:07 发布
阅读量711 收藏
点赞数
文章标签： oracle数据库 笛卡尔积
这篇博客探讨了一个复杂的SQL查询，其中发现了高成本的笛卡尔积操作。建议通过去除孤立的表或添加连接条件来重构SQL以提高效率。查询涉及到多个表的连接，并使用了笛卡尔积、索引和过滤条件，对数据库性能有显著影响。
摘要由CSDN通过智能技术生成

GENERAL INFORMATION SECTION

-------------------------------------------------------------------------------

Tuning Task Name                  : staName7918

Tuning Task Owner                 : VEASMS201501

Tuning Task ID                    : 65478

Scope                             : COMPREHENSIVE

Time Limit(seconds)               : 1800

Completion Status                 : COMPLETED

Started at                        : 05/22/2015 15:43:31

Completed at                      : 05/22/2015 15:43:35

Number of SQL Restructure Findings: 1

-------------------------------------------------------------------------------

Schema Name: VEASMS201501

SQL ID     : 95vtg3rzsb59b

SQL Text   : select DECODE(xl.xlly, '2', '3', '1') xljh,

j.lx,

j.CJ_COMPID compmc,

j.JHBH,

j.XLBH,

j.XLMC,

j.cfcs,

j.MDCS MDDMC,

j.JTGJ jtgjmc,

'0' from_tdd_jh,

'' tddh,

jr.cfrq CFRQ,

'' jzrq,

j.CJ_USERID jdyxm,

j.CJ_USERID jdyid,

xl.gysid,

j.ts,

xl.GYS_DEPTID,

xl.GYS_USERID,

xl.kdyje_zz,

xl.kdyje_dz,

j.by3,

j.jtzq,

j.jtgz,

xl.xlgg,

xl.bzbz,

j.rdxl,

j.tjxl,

j.yhxl,

0 zrs,

0 bwrs,

0 bmrs,

0 zwrs,

0 xzwrs

from LY_JH j,

ly_xl xl,

LY_XLJH_QW jq,

(select r.jhbh, min(r.cfrq) cfrq

from ly_jhrq r

where 1 = 1

AND r.CFRQ >= '2015-01-20'

AND r.CFRQ <= '2015-06-19'

and (zt = '0' or zt = '1')

and NOT EXISTS

(SELECT 1

FROM LY_TDD tdd

WHERE DJBH = R.JHBH

AND tdd.cfrq = r.cfrq

AND (DDZT = '7' OR

DDZT = '8'))

group by r.jhbh) jr

where j.xlbh = xl.xlbh

and (xl.xlly = '2' or

(xl.xlly = '1' and j.by3 = '0'))

AND XL.ZT <> '2'

and exists (select 1

from LY_JHJG g

where g.jhbh = j.jhbh

and g.JSLX = '1008001')

and j.ZGS = 'XYJ'

and j.jhlx = '1'

and jq.jhbh = j.jhbh

and contains(jq.qw, '线路') > 0

and jr.JHBH = j.jhbh

order by xlmc, cfrq

-------------------------------------------------------------------------------

FINDINGS SECTION (1 finding)

-------------------------------------------------------------------------------

1- Restructure SQL finding (see plan 1 in explain plans section)

----------------------------------------------------------------

在执行计划的行 ID 6 处发现开销很大的笛卡尔积操作。

Recommendation

--------------

- 考虑从此语句中移去断开连接的表或视图, 或者添加引用它的联接条件。

Rationale

---------

应尽可能避免笛卡尔积操作, 因为它的开销很大, 并且会产生大量数据。

-------------------------------------------------------------------------------

EXPLAIN PLANS SECTION

-------------------------------------------------------------------------------

1- Original

-----------

Plan hash value: 3609082328

-----------------------------------------------------------------------------------------------------

| Id  | Operation                          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |

-----------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                   |                |     3 |  3087 |    92   (7)| 00:00:02 |

|   1 |  SORT ORDER BY                     |                |     3 |  3087 |    92   (7)| 00:00:02 |

|   2 |   NESTED LOOPS                     |                |     3 |  3087 |    91   (6)| 00:00:02 |

|*  3 |    HASH JOIN                       |                |     6 |  5676 |    86   (6)| 00:00:02 |

|*  4 |     HASH JOIN                      |                |    16 | 14720 |    38   (6)| 00:00:01 |

|*  5 |      TABLE ACCESS FULL             | LY_JH          |  1251 |   151K|    21   (0)| 00:00:01 |

|   6 |      MERGE JOIN CARTESIAN          |                | 20910 |    15M|    16   (7)| 00:00:01 |

|   7 |       SORT UNIQUE                  |                |  3044 | 85232 |    15   (0)| 00:00:01 |

|*  8 |        INDEX FAST FULL SCAN        | UNI_LY_JHJG    |  3044 | 85232 |    15   (0)| 00:00:01 |

|   9 |       BUFFER SORT                  |                |   102 | 78336 |     1 (100)| 00:00:01 |

|  10 |        TABLE ACCESS BY INDEX ROWID | LY_XLJH_QW     |   102 | 78336 |    16   (7)| 00:00:01 |

|* 11 |         DOMAIN INDEX               | IDX_LY_XLJH_QW |       |       |     0   (0)| 00:00:01 |

|  12 |     VIEW                           |                |   433 | 11258 |    47   (5)| 00:00:01 |

|  13 |      HASH GROUP BY                 |                |   433 | 27712 |    47   (5)| 00:00:01 |

|* 14 |       HASH JOIN RIGHT ANTI         |                |   593 | 37952 |    46   (3)| 00:00:01 |

|  15 |        INLIST ITERATOR             |                |       |       |            |          |

|* 16 |         TABLE ACCESS BY INDEX ROWID| LY_TDD         |     1 |    32 |     4   (0)| 00:00:01 |

|* 17 |          INDEX RANGE SCAN          | IDX_LYTDD_DDZT |    21 |       |     2   (0)| 00:00:01 |

|* 18 |        INDEX FAST FULL SCAN        | IDX_LY_JHRQ1   |   593 | 18976 |    42   (3)| 00:00:01 |

|* 19 |    TABLE ACCESS BY INDEX ROWID     | LY_XL          |     1 |    83 |     1   (0)| 00:00:01 |

|* 20 |     INDEX UNIQUE SCAN              | PK_LY_XL       |     1 |       |     0   (0)| 00:00:01 |

-----------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):

-------------------------------------------------------------

1 - SEL$6590669A

5 - SEL$6590669A / J@SEL$1

8 - SEL$6590669A / G@SEL$4

10 - SEL$6590669A / JQ@SEL$1

11 - SEL$6590669A / JQ@SEL$1

12 - SEL$BE5C8E5F / JR@SEL$1

13 - SEL$BE5C8E5F

16 - SEL$BE5C8E5F / TDD@SEL$3

17 - SEL$BE5C8E5F / TDD@SEL$3

18 - SEL$BE5C8E5F / R@SEL$2

19 - SEL$6590669A / XL@SEL$1

20 - SEL$6590669A / XL@SEL$1

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("JR"."JHBH"="J"."JHBH")

4 - access("JQ"."JHBH"="J"."JHBH" AND "G"."JHBH"="J"."JHBH")

5 - filter("J"."ZGS"='XYJ' AND "J"."JHLX"='1')

8 - filter("G"."JSLX"='1008001')

11 - access("CTXSYS"."CONTAINS"("JQ"."QW",'线路')>0)

14 - access("DJBH"="R"."JHBH" AND "TDD"."CFRQ"="R"."CFRQ")

16 - filter("TDD"."CFRQ"<='2015-06-19' AND "TDD"."CFRQ">='2015-01-20')

17 - access("DDZT"='7' OR "DDZT"='8')

18 - filter("R"."CFRQ"<='2015-06-19' AND "R"."CFRQ">='2015-01-20' AND ("ZT"='0' OR

"ZT"='1'))

19 - filter("XL"."ZT"<>'2' AND ("XL"."XLLY"='1' OR "XL"."XLLY"='2') AND ("XL"."XLLY"='2'

OR "XL"."XLLY"='1' AND "J"."BY3"='0'))

20 - access("J"."XLBH"="XL"."XLBH")

Column Projection Information (identified by operation id):

-----------------------------------------------------------

1 - (#keys=2) "J"."XLMC"[VARCHAR2,200], "JR"."CFRQ"[VARCHAR2,10],

DECODE("XL"."XLLY",'2','3','1')[1], "J"."LX"[VARCHAR2,10], "J"."CJ_COMPID"[VARCHAR2,10],

"J"."JHBH"[VARCHAR2,30], "J"."XLBH"[VARCHAR2,30], 0[1], "J"."CFCS"[VARCHAR2,10],

"J"."MDCS"[VARCHAR2,10], "J"."JTGJ"[VARCHAR2,10], '0'[1], ''[0], 0[1], ''[0],

"J"."CJ_USERID"[VARCHAR2,20], "J"."CJ_USERID"[VARCHAR2,20], "XL"."GYSID"[VARCHAR2,20],

"J"."TS"[NUMBER,22], "XL"."GYS_DEPTID"[VARCHAR2,20], "XL"."GYS_USERID"[VARCHAR2,20],

"XL"."KDYJE_ZZ"[NUMBER,22], "XL"."KDYJE_DZ"[NUMBER,22], "J"."BY3"[VARCHAR2,100],

"J"."JTZQ"[VARCHAR2,1], "J"."JTGZ"[VARCHAR2,4000], "XL"."XLGG"[VARCHAR2,1000],

"XL"."BZBZ"[VARCHAR2,200], "J"."RDXL"[VARCHAR2,1], "J"."TJXL"[VARCHAR2,1],

"J"."YHXL"[VARCHAR2,1], 0[1], 0[1], 0[1]

2 - (#keys=0) "J"."JHBH"[VARCHAR2,30], "J"."JHBH"[VARCHAR2,30], "J"."YHXL"[VARCHAR2,1],

"J"."XLBH"[VARCHAR2,30], "J"."XLMC"[VARCHAR2,200], "J"."LX"[VARCHAR2,10],

"J"."TS"[NUMBER,22], "J"."JTZQ"[VARCHAR2,1], "J"."JTGZ"[VARCHAR2,4000],

"J"."RDXL"[VARCHAR2,1], "J"."TJXL"[VARCHAR2,1], "J"."CFCS"[VARCHAR2,10],

"J"."MDCS"[VARCHAR2,10], "J"."JTGJ"[VARCHAR2,10], "J"."CJ_USERID"[VARCHAR2,20],

"J"."CJ_COMPID"[VARCHAR2,10], "J"."BY3"[VARCHAR2,100], "JR"."CFRQ"[VARCHAR2,10],

"XL"."BZBZ"[VARCHAR2,200], "XL"."XLLY"[VARCHAR2,1], "XL"."GYSID"[VARCHAR2,20],

"XL"."GYS_DEPTID"[VARCHAR2,20], "XL"."GYS_USERID"[VARCHAR2,20], "XL"."XLGG"[VARCHAR2,1000],

"XL"."KDYJE_ZZ"[NUMBER,22], "XL"."KDYJE_DZ"[NUMBER,22]

3 - (#keys=1) "J"."JHBH"[VARCHAR2,30], "J"."JHBH"[VARCHAR2,30], "J"."YHXL"[VARCHAR2,1],

"J"."XLBH"[VARCHAR2,30], "J"."XLMC"[VARCHAR2,200], "J"."LX"[VARCHAR2,10],

"J"."TS"[NUMBER,22], "J"."JTZQ"[VARCHAR2,1], "J"."JTGZ"[VARCHAR2,4000],

"J"."RDXL"[VARCHAR2,1], "J"."TJXL"[VARCHAR2,1], "J"."CFCS"[VARCHAR2,10],

"J"."MDCS"[VARCHAR2,10], "J"."JTGJ"[VARCHAR2,10], "J"."CJ_USERID"[VARCHAR2,20],

"J"."CJ_COMPID"[VARCHAR2,10], "J"."BY3"[VARCHAR2,100], "JR"."CFRQ"[VARCHAR2,10]

4 - (#keys=2) "J"."JHBH"[VARCHAR2,30], "JQ"."JHBH"[VARCHAR2,30], "J"."JHBH"[VARCHAR2,30],

"G"."JHBH"[VARCHAR2,30], "J"."YHXL"[VARCHAR2,1], "J"."JHLX"[VARCHAR2,10],

"J"."XLBH"[VARCHAR2,30], "J"."XLMC"[VARCHAR2,200], "J"."LX"[VARCHAR2,10],

"J"."TS"[NUMBER,22], "J"."JTZQ"[VARCHAR2,1], "J"."JTGZ"[VARCHAR2,4000],

"J"."RDXL"[VARCHAR2,1], "J"."TJXL"[VARCHAR2,1], "J"."CFCS"[VARCHAR2,10],

"J"."MDCS"[VARCHAR2,10], "J"."JTGJ"[VARCHAR2,10], "J"."CJ_USERID"[VARCHAR2,20],

"J"."CJ_COMPID"[VARCHAR2,10], "J"."ZGS"[VARCHAR2,10], "J"."BY3"[VARCHAR2,100],

"JQ"."QW"[LOB,4000], "JQ".ROWID[ROWID,10]

5 - "J"."JHBH"[VARCHAR2,30], "J"."JHLX"[VARCHAR2,10], "J"."XLBH"[VARCHAR2,30],

"J"."XLMC"[VARCHAR2,200], "J"."LX"[VARCHAR2,10], "J"."TS"[NUMBER,22],

"J"."JTZQ"[VARCHAR2,1], "J"."JTGZ"[VARCHAR2,4000], "J"."RDXL"[VARCHAR2,1],

"J"."TJXL"[VARCHAR2,1], "J"."CFCS"[VARCHAR2,10], "J"."MDCS"[VARCHAR2,10],

"J"."JTGJ"[VARCHAR2,10], "J"."CJ_USERID"[VARCHAR2,20], "J"."CJ_COMPID"[VARCHAR2,10],

"J"."ZGS"[VARCHAR2,10], "J"."BY3"[VARCHAR2,100], "J"."YHXL"[VARCHAR2,1]

6 - (#keys=0) "G"."JHBH"[VARCHAR2,30], "JQ".ROWID[ROWID,10], "JQ"."JHBH"[VARCHAR2,30],

"JQ"."QW"[LOB,4000]

7 - (#keys=1) "G"."JHBH"[VARCHAR2,30]

8 - "G"."JHBH"[VARCHAR2,30], "G"."JSLX"[VARCHAR2,10]

9 - (#keys=0) "JQ".ROWID[ROWID,10], "JQ"."JHBH"[VARCHAR2,30], "JQ"."QW"[LOB,4000]

10 - "JQ".ROWID[ROWID,10], "JQ"."JHBH"[VARCHAR2,30], "JQ"."QW"[LOB,4000]

11 - "JQ".ROWID[ROWID,10], "JQ"."JHBH"[VARCHAR2,30], "JQ"."QW"[LOB,4000]

12 - "JR"."JHBH"[VARCHAR2,30], "JR"."CFRQ"[VARCHAR2,10]

13 - (#keys=1) "R"."JHBH"[VARCHAR2,30], MIN("R"."CFRQ")[10]

14 - (#keys=2) "R"."JHBH"[VARCHAR2,30], "R"."CFRQ"[VARCHAR2,10]

15 - "TDD"."CFRQ"[VARCHAR2,10], "DJBH"[VARCHAR2,30]

16 - "TDD"."CFRQ"[VARCHAR2,10], "DDZT"[VARCHAR2,1], "DJBH"[VARCHAR2,30]

17 - "TDD".ROWID[ROWID,10], "DDZT"[VARCHAR2,1]

18 - "R"."JHBH"[VARCHAR2,30], "R"."CFRQ"[VARCHAR2,10]

19 - "XL"."BZBZ"[VARCHAR2,200], "XL"."XLLY"[VARCHAR2,1], "XL"."GYSID"[VARCHAR2,20],

"XL"."GYS_DEPTID"[VARCHAR2,20], "XL"."GYS_USERID"[VARCHAR2,20], "XL"."XLGG"[VARCHAR2,1000],

"XL"."KDYJE_ZZ"[NUMBER,22], "XL"."KDYJE_DZ"[NUMBER,22]

20 - "XL".ROWID[ROWID,10]

-------------------------------------------------------------------------------

Up酱彡
关注
oracle性能优化之多表关联发生笛卡尔积及解决办法
springqingchun的专栏
05-17 7690
oracle两张表进行关联的时候，只要不是特意去做，很难出现笛卡尔积的情况，但是多张关联的时候可就要小心了。即使你的条件中，表已经两两关联，但有些情况下还是可能会出现笛卡尔积的。 昨天有一个oracle的sql，都执行了6个月了，一直没有出现问题，可昨天就出现临时空间爆满的情况，查看报错的sql，然后在pl\sql里按F5，看了一下执行计划，发现竟然产生的笛卡尔积，真是郁闷的要死。 首先贴一下
oracle数据库 笛卡尔积,Oracle连接查询和笛卡尔积
weixin_32584807的博客
04-03 1718
一、内连接和外连接内连接用于返回满足连接条件的记录；而外连接则是内连接的扩展，它不仅会满足连接条件的记录，而且还会返回不满足连接条件的记录，语法如下：selecttable1.column,table2.columnfromtable1[inner|left|right|full]jointable2ontable1.column=table2.column;inner join表示...
笛卡尔积产生的原因
只管努力，莫问前程
12-07 3013
首先说下结论：链接查询，如果on条件是非唯一字段，会出现笛卡尔积(局部笛卡尔积)；如果on条件是表的唯一字段，则不会出现笛卡尔积。 测试大法： 首先构建两张表，一张用户表（5条数据）、一张工作部门表（4条数据）。 CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `addr` varchar(255) DEFAULT NULL, `email` var
笛卡尔积形成的原因
weixin_55579895的博客
12-12 1511
原因 因为多表之间没有限制，表中的每一行数据任意组合 笛卡尔积 笛卡尔积请具体解释一下 数据库中的数据都是以二维表的形式存放的,元组就是表格的行,分量就是其中的每个字段,字段就是这一行的 每一的小的标题.笛卡儿积就是把两个表中的不同的行相乘,笛卡儿积的结果的表格的行数就是两个相乘的表格的的行数的乘积,分量的数目就是两个表格的分量数目相加. 说白了，就是一个集合里的每一个元素和另一个集合的每一个元素“交配”一下的结果。 例如集合A1={1，2，3}，集合A2={4，5，6} A1*A2（*表示笛卡尔集合）={
OR导致笛卡尔积
莫等闲
10-24 1095
最近监控数据库，发现下面语句跑得非常慢，原来执行计划走了导致笛卡尔积，来看下面语句： SQL> explain plan for 2 SELECT COUNT(*) 3 FROM "GD_FS"."TZZ_SJ_DEV_DISC_79073" "A2", 4 "GD_FS"."TZZ_SJ_DEVELOP_MONTH" "A1" 5 WHERE "A
mysql 内连接出现笛卡尔积原因及解决办法
weixin_43392868的博客
09-05 5067
本来每个表的结果只有两条 经过内连接查询后,结果居然变成了四条,出现了笛卡尔积... 参考了https://blog.csdn.net/zy_281870667/article/details/81046573,发现了出现笛卡尔积的原因: 字段 ORDER_NUM并不唯一,所以出现了局部笛卡尔积(查询条件内的笛卡尔积,而不是全表笛卡尔积) 解决办法 换了另外一个具有唯一...
笛卡尔积
carl_jiang的专栏
11-19 927
product 查询有7条数据 productiontask 有 11 条数据 接下来进行笛卡尔积： 笛卡尔积之后的条数就是他们条数的积
笛卡尔积oracle,执行计划中出现笛卡尔积
weixin_33978722的博客
04-04 895
SELECT t3.h_city,t3.h_a_code,t3.c_a_code,t3.b_id,COUNT(DISTINCT t1.userid)FROMtmp_bam_ochat_order_m_xzw t1INNER JOIN tmp_bam_ochat_cactive_m_xzw t2ON t1.userid = t2.useridAND t2.s_month = 201108INNER ...
数据库系统概念 关系和笛卡尔积
weixin_47005624的博客
04-18 1万+
一、关系 关系模型建立在集合代数的基础上； 单一的数据结构----关系 现实世界的实体以及实体间的各种联系均用关系来表示 逻辑结构----二维表 从用户角度，关系模型中数据的逻辑结构是一张二维表，它由行和列组成。 关系模式 对关系（结构）（特征）（性质）的描述 关系名（属性1，属性2，…，属性n） R(U) 学生（学号，姓名，年龄，性别，系，年级） 补充：域 域是一组具有相同数据类型的值的...
数据库之SQL笛卡尔积
04-19 7147
数据库之SQL笛卡尔积 1.笛卡尔积定义 笛卡尔积在SQL中的实现方式既是交叉连接(Cross Join)。所有连接方式都会先生成临时笛卡尔积表，笛卡尔积是关系代数里的一个概念，表示两个表中的每一行数据任意组合,上图中两个表连接即为笛卡尔积(交叉连接)...
左连接left join产生的是笛卡尔积，再根据on条件筛选结果
liucan2010leo的博客
07-13 4242
看菜鸟教程里左连接的讲解https://www.runoob.com/mysql/mysql-join.html 里面提到 LEFT JOIN（左连接）：获取左表所有记录，即使右表没有对应匹配的记录。 被其误导了，导致我一个下午都不明白我一段SQL查询结果。 最终豁然开朗。 结论是left join左连接产生的是笛卡尔积，即两个10行的表左连接，首先是生成一个10*10行的表，然后根据on后面的条件筛选符合条件的行。 先放上其他博文的评论支持这一观点 先看我的应用的一段代码 create table
oracle的笛卡尔积的用处,笛卡尔积的解释和作用
weixin_39831705的博客
04-04 1492
一：笛卡尔积的解释例 给出二个域：假设集合A={a,b}，集合B={0,1,2}，则两个集合的笛卡尔积为{(a,0),(a,1),(a,2),(b,0),(b,1),(b,2)}。。类似的例子有，如果A表示某学校学生的集合，B表示该学校所有课程的集合，则A与B的笛卡尔积表示所有可能的选课情况。 [编辑本段]笛卡尔积的运算性质　　由于有序对中x,y的位置是确定的，因此A×B的记法也是确定的，不能写成...
Oracle多表查询 –工作中避免笛卡儿积的出现
微笑一号的博客
08-13 2532
Oracle多表查询 –工作中避免笛卡儿积的出现
数据库表联查出现的笛卡尔积
搬砖刘疯狂
09-17 4510
一、笛卡尔积定义 笛卡尔乘积是指在数学中，两个集合X和Y的笛卡尓积（Cartesian product），又称直积，表示为X*Y，第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员 。 假设集合A={a, b}，集合B={0, 1, 2}，则两个集合的笛卡尔积为{(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}。 二、笛卡尔积出现的原因 比如我们有两张表user和school SELECT a.user_id, b.sc.
数据库Oracle之多表查询：笛卡尔积、等值连接、不等值连接、外连接，自连接
热门推荐
wu5215080的专栏
09-14 2万+
 1 笛卡尔积  列数 相加  行数 记录相乘      SQL> ed   已写入 file afiedt.buf        1  select count(*)     2* from dept, emp   SQL> /        COUNT(*)   ----------           56      通过连接条件可以避免笛卡尔积   
oracle视图hint,请问这个复杂视图的ｈｉｎｔ怎么加
weixin_39989973的博客
04-14 152
GENERAL INFORMATION SECTION-------------------------------------------------------------------------------Tuning Task Name : my_sql_tuning_task1Tuning Task Owner: SYSWorkload Type : Single SQ...
深入解析Oracle数据库中的笛卡尔积连接
最新发布
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
03-27 705
由于笛卡尔积连接往往产生大量的结果，而且在大多数情况下这些结果并不具备实际意义，所以在业务逻辑上通常不是期望的结果。在实践中，通常会在连接条件中指定某种关联性（如两个表的共同列值相等），以限制结果集的大小并获得有意义的数据集合。在Oracle数据库中，笛卡尔积连接（也称为交叉连接，Cross Join）是指两个表之间没有指定任何连接条件时进行的连接操作。这种连接将第一个表中的每一行与第二个表中的每一行进行配对，生成的结果集包含了所有可能的行组合，其大小等于第一个表的行数乘以第二个表的行数。
数据库作业7：SQL练习4 - SELECT（连接查询、嵌套查询）
weixin_45871977的博客
03-18 4368
数据查询2—连接查询:同时涉及两个以上的表的查询 连接条件：用来连接两个表的条件 [<表名1>.]<列名1> <比较运算符> [<表名2>.]<列名2> 连接字段：连接条件中的列名称(注意：连接字段类型必须是可比的，但名字不必相同) 连接查询—(1)等值与非等值连接查询:等值连接：连接运算符为=（对比关系代数中的等值连接） 【例3....
Oracle 高级查询：内外连接、子查询、exists 查询、rownum 行号、offset rows fetch first/next 分页、集合运算, Sql 执行顺序
蚩尤后裔-汪茂雄
06-02 4127
目录 笛卡尔积 隐式内连接 显式内连接 左/右外连接 子查询 exists 查询 rownum 行号 union 并集运算 minus 差集运算 集合运算注意事项 笛卡尔积 1、两张表数据的乘积，实际基本用不上，只是助于理解。 select * from emp;--查询所有员工 select * from dept;--查询所有部门 select * from emp...
Oracle数据库查询教程：多表连接与笛卡尔积解析
此外，笔记中还介绍了SQL的1999标准对SQL语言的一些扩展支持，例如交叉连接（CROSS JOIN），它会产生两个表的笛卡尔积，即每个左表记录与右表的所有记录组合。这种连接在没有明确连接条件时，会导致结果集的大小为两...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值