树概念及使用connect by进行级联查询
树
树,大家都见过,以这种形式的数据关系,就是树。下面看一张图,了解什么是根节点(树干)、节点或分叉、叶(叶节点)

connect by 级联查询
connect by可以用于级联查询,常用于对具有树状结构的记录查询某一节点的所有子孙节点或所有祖辈节点。
来看一个示例,现假设我们拥有一个菜单表t_menu,其中只有三个字段:id、name和parent_id。它们是具有父子关系的,最顶级的菜单对应的parent_id为0。现假设我们拥有如下记录:
|
id |
name |
parent_id |
|
1 |
菜单01 |
0 |
|
2 |
菜单02 |
0 |
|
3 |
菜单03 |
0 |
|
4 |
菜单0101 |
1 |
|
5 |
菜单0102 |
1 |
|
6 |
菜单0103 |
1 |
|
7 |
菜单010101 |
4 |
|
8 |
菜单010201 |
5 |
|
9 |
菜单010301 |
6 |
|
10 |
菜单0201 |
2 |
|
11 |
菜单0202 |
2 |
|
12 |
菜单020101 |
10 |
|
13 |
菜单020102 |
10 |
|
14 |
菜单020103 |
10 |
|
15 |
菜单0301 |
3 |
|
16 |
菜单0302 |
3 |
|
17 |
菜单030201 |
16 |
|
18 |
菜单030202 |
16 |
|
19 |
菜单030203 |
16 |
如果这个时候我们需要查询“菜单01”以及其下所有的子孙菜单应该怎么办呢?如果使用connect by的话这将会非常简单,使用如下SQL语句就可以达到对应的效果。
connect by是需要跟start with一起使用的。connect by后跟的是连接条件,在connect by后接的条件通常都需要使用关键字“prior”,可以简单的把它理解为上一级,所以上述例子中“connect by parent_id=prior id”就表示连接条件为parent_id等于上级的id,查找到下一级记录后又会找parent_id等于下一级记录的id的记录,而prior对应的最顶层的记录就是通过start with来确定的,start with后接对应的筛选条件,表示最顶层的记录是哪些,最顶层的记录可以有多个,比如我想查找“菜单01”下的子孙菜单,但是不包括“菜单01”本身,那么我就可以使用如下的SQL语句进行查找,此时“start with parent_id=1”对应的记录就会有多条。
对应的结果为:
|
id |
name |
parent_id |
|
4 |
菜单0101 |
1 |
|
5 |
菜单0102 |
1 |
|
6 |
菜单0103 |
1 |
|
7 |
菜单010101 |
4 |
|
8 |
菜单010201 |
5 |
|
9 |
菜单010301 |
6 |
此外,如果我们想查找“菜单010101”对应的祖辈菜单也非常简单,如下SQL就可以实现该功能,即从“菜单010101”的父菜单(对应id为4)开始查找。
对应的结果为:
|
id |
name |
parent_id |
|
1 |
菜单01 |
0 |
|
4 |
菜单0101 |
1 |
level
使用connect by时我们可以使用内置的类似于rownum的一个叫level的伪列,该列表示当前记录相对于start with记录的一个层级,start with记录的level为1。如上面的两条SQL语句,如果加上level的话对应的结果将是这样的。
对应的结果为:
|
level |
id |
name |
parent_id |
|
1 |
4 |
菜单0101 |
1 |
|
1 |
5 |
菜单0102 |
1 |
|
1 |
6 |
菜单0103 |
1 |
|
2 |
7 |
菜单010101 |
4 |
|
2 |
8 |
菜单010201 |
5 |
|
2 |
9 |
菜单010301 |
6 |
对应的结果为:
|
level |
id |
name |
parent_id |
|
2 |
1 |
菜单01 |
0 |
|
1 |
4 |
菜单0101 |
1 |
有了level后,我们就可以对查询的level做一个限制,比如只查从最顶层开始向下两级的菜单。
从上述SQL我们可以看到where条件是直接跟在from之后的,使用connect by时我们的where条件不是在connect by之前对数据进行过滤的,而是在connect by之后才对所有的数据进行过滤的,这一点跟使用分组语句group by时是不一样的,group by是先通过where对需要分组的数据进行过滤后再通过group by来分组的。
nocycle和connect_by_iscycle
如果我们的记录中存在循环的父子关系,则使用connect by进行查询时会抛出异常,如A->B、B->C、C->A这样的记录。解决办法是在connect by语句后加上“nocycle”,表示不循环查询,如:
使用nocycle后对于A->B、B->C、C->A这样的记录会通过查询B,然后通过B查询C,再通过C查询A时发现已经循环了,就不再查询了,即在C这条记录这里循环了。在对存在循环记录的查询中我们也可以通过“connect_by_iscycle”找到是哪一条记录循环了,“connect_by_iscycle”也是一个伪列,其必须和nocycle一起使用。伪列“connect_by_iscycle”对应的值有0和1,如果某一条记录的connect_by_iscycle对应的值为1则表示从该条记录这里开始循环了。如下是一个使用connect_by_iscycle的示例。
connect_by_isleaf
connect_by_isleaf也是一个伪列,其表示对应的记录是否是一个叶子节点,即在进行connect by时不能通过该记录找到下一条记录。其对应的值有0和1,0表示非叶子节点,1表示是叶子节点。如我只想找出是叶子节点的菜单时对应的SQL可以这样写:
connect_by_root
connect_by_root表示根节点,即某一条记录所对应的最顶级的记录,其用法跟prior类似,后面也需要跟一个字段名。如下面示例可以查询所有叶子节点菜单的最顶级菜单和上级菜单的名称。
select connect_by_root name as root_name, prior name as prior_name,t.* from t_menu t where connect_by_isleaf=1 connect by prior id=parent_id start with parent_id=0;
对应上表的记录,在上述SQL中查询出来的结果应该如下所示:
|
root_name |
prior_name |
id |
name |
parent_id |
|
菜单01 |
菜单0101 |
7 |
菜单010101 |
4 |
|
菜单01 |
菜单0102 |
8 |
菜单010201 |
5 |
|
菜单01 |
菜单0103 |
9 |
菜单010301 |
6 |
|
菜单02 |
菜单02 |
11 |
菜单0202 |
2 |
|
菜单02 |
菜单0201 |
12 |
菜单020101 |
10 |
|
菜单02 |
菜单0201 |
13 |
菜单020102 |
10 |
|
菜单02 |
菜单0201 |
14 |
菜单020103 |
10 |
|
菜单03 |
菜单03 |
15 |
菜单0301 |
3 |
|
菜单03 |
菜单0302 |
17 |
菜单030201 |
16 |
|
菜单03 |
菜单0302 |
18 |
菜单030202 |
16 |
|
菜单03 |
菜单0302 |
19 |
菜单030203 |
16 |
sys_connect_by_path
sys_connect_by_path(column,delimiter)可以用来展示以指定column和分隔符delimiter表示从根节点到当前节点的路径。以下SQL用来查询id为2的菜单下叶子节点的信息,包括以字段name和分隔符“>”表示的其对应的根节点的路径。
对应结果如下所示:
|
connect_path |
id |
name |
parent_id |
|
>菜单02>菜单0202 |
11 |
菜单0202 |
2 |
|
>菜单02>菜单0202>菜单020101 |
12 |
菜单020101 |
10 |
|
>菜单02>菜单0202>菜单020102 |
13 |
菜单020102 |
10 |
|
>菜单02>菜单0202>菜单020103 |
14 |
菜单020103 |
10 |
排序order
可以使用order by对connect by之后的结果进行排序,此时order by需放在最末端,而不像where筛选那样直接定义在from之后。如需对connect by之后的结果按id进行排序,则可以使用如下SQL语句:
除了传统的针对查询结果的排序外,connect by语句还支持对同一父节点下的子节点进行排序,这是通过order siblings by来定义的。如我们需要查询id为2的菜单下的所有子孙菜单,然后对具有同一父节点的菜单按id进行倒序排列,则我们的SQL语句可以如下定义:
对应的结果会是这样子:
|
id |
name |
parent_id |
|
2 |
菜单02 |
0 |
|
11 |
菜单0202 |
2 |
|
10 |
菜单0201 |
2 |
|
14 |
菜单020103 |
10 |
|
13 |
菜单020102 |
10 |
|
12 |
菜单020101 |
10 |
如上表所示,我们可以看到“菜单0201”和“菜单0202”具有相同的父节点“菜单02”,它们按照id进行倒序排列,所有“菜单0202”在“菜单0201”之前,同样“菜单020101”、“菜单020102”和“菜单020103”具有相同的父节点“菜单0201”,所以它们也是按照id的倒序排列。
一次针对connect by的查询优化
有这么一个需求:表A表示分类,表B表示任务模板,A与B是一对多的关系,每一个任务模板都属于一个特定的分类,在表B中用字段a表示所属的分类。分类存在父子关系,子分类的parent_id对应父分类的id。现假设需要统计id为1的分类及其子分类下存在的任务模板数量。对应SQL如下:
现假设拥有另外一个表C,其表示任务实例,一个任务模板B可以拥有n个任务实例B,即B跟C之间是一对多的关系。任务实例C通过字段b关联任务模板B,另外任务实例C拥有一个字段status表示任务实例的具体状态。现假设需要统计id为1的分类及其子分类下各状态的任务实例数量。对应SQL如下:
在A表数据量1000,B表数据量20000,C表数据量5000,id为1的分类下属的子孙分类数量为100的情况下第一条SQL的查询速度可以在0.1秒左右完成,而第二条SQL需要将近10秒才能完成。把查询id为1的分类下子孙分类的id的SQL语句“selectidfrom A connectbypriorid=parent_id startwithid=1”单独查询的速度也可以在0.1秒内完成。通常对于这种数量级别的三表查询都是可以在0.1秒内完成的,为此心想第二条SQL应该是受了子查询中connect by的影响。后来决定把分类的子查询直接作为B的in条件进行查询,如下所示:
其查询效果是一样的,心想应该还是connect by影响到了,既然单独使用connect by查询id为1的分类的子孙分类的id只需要不到0.1秒,那何不在程序里面先将id为1的分类的子孙分类id查询出来,再作为B、C联合查询的in条件,如:
结果查询结果也可以在0.1秒内完成。
思考
假设需要求菜单parentId为16的数据到菜单03的路径,用下面代码
select *,sys_connect_by_path(name,'/') from t_menu where parent_id = 16 start with id is not null connect by prior id = parent_id
得出的是每个节点往下的路径。
把prior 放在parent_id 前面,可以得出全路径,但是不好提取到根的路径。而且如果数据库很大, start with 用 is not null 会很慢。
如果这样操作:

select * from t_menu t
left join (
select connect_by_root id as id ,sys_connect_by_path(name,'/') path
from t_menu
where id=3
start with (select id from t_menu where parent_id =16)
connect by id =prior parent_id) t1
on t.id=t1.id

用connect_by_root 来取出path的actul id,再和原表左联。会不会好一点?
树概念及使用connect by进行级联查询的更多相关文章
- oracle使用connect by进行级联查询 树型菜单
Oracle使用connect by进行级联查询 树型菜单(转) connect by可以用于级联查询,常用于对具有树状结构的记录查询某一节点的所有子孙节点或所有祖辈节点. 来看一个示例,现假设我们拥 ...
- Oracle级联查询
在ORACLE 数据库中有一种方法可以实现级联查询 select * //要查询的字段 from table //具有子接点ID与父接点I ...
- ORACLE 数据库的级联查询 一句sql搞定(部门多级)
在ORACLE 数据库中有一种方法可以实现级联查询 select * //要查询的字段 from table //具有子接点ID与父接点I ...
- oracle 级联查询 根路径
级联查询有很多教程示例,但是没有找到求特定子孙到根的路径的例子,折腾了一番总算想出方法了. 现假设我们拥有一个菜单表t_menu,其中只有三个字段:id.name和parent_id.它们是具有父子关 ...
- 【java】itoo项目实战之大数据查询之使用 new map 优化hibernate之级联查询
在我的上一篇博客<[java]itoo项目实战之hibernate 懒载入优化性能>中,我曾提到过学生数据有2万条,查询数据十分的慢,这是让人非常受不了的事情.看着页面进度条一直转着圈圈, ...
- Oracle恢复删除数据 && connect by 树形结构查询
1.一个表中根据以父子级别关系查询显示出来(如图) select t.* from department t CONNECT BY PRIOR t.depid=t.supdepid ; --这样也可以 ...
- Mybatis 级联查询 (一对多 )
后台系统中 涉及到添加试卷 问题 答案的一个模块的.我需要通过试卷 查询出所有的试题,以及试题的答案.这个主要要使用到Mybatis的级联查询. 通过试卷 查询出与该试卷相关的试题(一对多),查询出试 ...
- Mybatis 之级联查询 一对多配置
Mybatis级联 查询相对于hibenate是有点麻烦,但是相应好处也是有的,Mybatis轻量.根据自己要的字段配置方便 一对多配置用 <collection property=&quo ...
- 三级级联查询省份名称和编码(保证名称不重复)的SQL语句
三级级联查询省份名称和编码(保证名称不重复)的SQL语句 1.省份.地市和县级数据库表 2.SQL语句 SELECT DISTINCT t.`province_name`,t.`province_co ...
随机推荐
- css3 伪元素和伪类选择器详解
转自脚本之家:http://www.jb51.net/css/213779.html 无论是伪类还是伪元素,都属于CSS选择器的范畴.所以它们的定义可以在CSS标准的选择器章节找到.分别是 CSS2. ...
- 专访探探DBA张文升:PG在互联网应用中同样也跑的很欢畅
张文升认为,PG无论在可靠性和性能方面都不输其它任何关系型数据库 张文升,探探DBA,负责探探的数据库架构.运维和调优的工作.拥有8年开发经验,曾任去哪儿网DBA. 9月24日,张文升将参加在 ...
- 【html/css】模态框的实现
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title> ...
- post字符 特殊字符处理【转】
今天和同事调试接口,由于产品设计的问题,传递的参数没有做任何的限制.同事就在传参数的时候加了些特殊字符到后台,但是后台打印的日志是 null... 然后上网搜了下解决办法:转 https://www. ...
- 常用sql commands以及mysql问题解决日志
mysql workbench常用命令快捷键 ctrl+T ->创建新的sql query tab ctrl+shift+enter->执行当前的sql命令 https://dev.mys ...
- 类型“Microsoft.Office.Interop.Word.ApplicationClass”错误 4317 无法嵌入互操作类型
类型“Microsoft.Office.Interop.Word.ApplicationClass”错误 4317 无法嵌入互操作类型“Microsoft.Office.Interop.Word.Ap ...
- 一、C#简单读写
using System.IO; static string configFileName = "config.json"; //不存在就直接新建文件夹 public static ...
- [翻译] ZFTokenField
ZFTokenField 本人视频教程系类 iOS中CALayer的使用 效果图: iOS custom view that let you add token view inside like ...
- VS2017配置cuda9.1编译不过问题。
#if defined(_WIN32) #if _MSC_VER < 1600 || _MSC_VER > 1920 #error -- unsupported Microsoft Vis ...
- 初探BeEF
1.什么是BeEF? 就是 The Browser Exploitation Framework 的缩写,意在通过一些手段,控制对方的浏览器. 里面集成了很多模块,能够获取很多东西,有cookie,浏 ...