递归的实际业务场景之MySQL 递归查询

喜欢就点个赞呗!
源码<--请点击此处查看

引入

当我看到一些评论时,例如下面的样子。我挺好奇这个功能是怎么样做出来的。进过查阅资料,发现这其实是 MySQL 的递归操作。下面就让我操作一下怎么实现 MySQL 的递归查询。

设计数据库

观察这种数据库设计,你会发现他都有一个父节点,一直到根节点,所以我们设计数据库的时候,应该设置一个 parentid 字段。所以,我们可以得到以下的数据库。

sql 脚本如下

CREATE TABLE digui(
    id INT(11) NOT null auto_increment,
    msg VARCHAR(255) not NULL COMMENT '评论的内容',
    parentid int(11) not null COMMENT '上一条',
    PRIMARY KEY(id)
)ENGINE=INNODB auto_increment = 100 DEFAULT CHARSET=utf8mb4;

INSERT into `digui`(msg, parentid) VALUES ('A', 0);
INSERT into `digui`(msg, parentid) VALUES('B', 1);
INSERT into `digui`(msg, parentid) VALUES('D', 3);
INSERT into `digui`(msg, parentid) VALUES('C', 2);

其实实现 MySQL 的递归查询方法有很多

  1. 使用 MySQL 存储过程
  2. 应用层代码递归
  3. MyBatis 的 collection 标签

方案1 应用层代码递归

//应用层递归查询
@Override
public List<Digui> getAll(int parent) {
    List<Digui> deptVosList=new ArrayList<>();
    QueryWrapper queryWrapper = new QueryWrapper();
    queryWrapper.eq("parentid", parent);
    List<Digui> list1 = list(queryWrapper);
    for (Digui digui: list1) {
        Digui digui1 = new Digui();
        digui1.setId(digui.getId());
        digui1.setMsg(digui.getMsg());
        digui1.setParentid(digui.getParentid());
        // 此处递归调用赋值
        digui1.setDiguiList(getAll(digui.getId()));
        deptVosList.add(digui1);
    }
    return deptVosList;

}

方案2 MyBatis 的 collection 标签

 <resultMap id="RecursiveMap" type="com.example.lsbdigui.entity.Digui">
        <result property="id" column="id"/>
        <result property="msg" column="msg"/>
        <result property="parentid" column="parentid"/>
        <collection property="diguiList" ofType="com.example.lsbdigui.entity.Digui"
                    select="com.example.lsbdigui.mapper.DiguiMapper.getAllBySQL"
                    column="id"/>
</resultMap>
<select id="getAllBySQL" resultMap="RecursiveMap">
    select *
    from digui
    where parentid = #{parent}
</select>

使用<collection><select>标签实现 sql 递归查询。

结果

{
    "code": 200,
    "msg": "正确返回",
    "date": [
        {
            "id": 100,
            "msg": "A",
            "parentid": 0,
            "diguiList": [
                {
                    "id": 101,
                    "msg": "B",
                    "parentid": 100,
                    "diguiList": [
                        {
                            "id": 103,
                            "msg": "C",
                            "parentid": 101,
                            "diguiList": [
                                {
                                    "id": 102,
                                    "msg": "D",
                                    "parentid": 103,
                                    "diguiList": []
                                }
                            ]
                        }
                    ]
                }
            ]
        }
    ]
}

对比

建议

应用层可以一次查询全部数据,然后再递归找出需要的数据,这样可以减少数据库查询,性能更佳。

参考

  • https://blog.rxliuli.com/p/5830226b/
  • https://juejin.im/entry/59be34fe5188257e8b36a303
  • https://blog.csdn.net/u014079773/article/details/53338116

关注微信公众号,随时移动端阅读

原文地址:https://www.cnblogs.com/chenzhuantou/p/12054387.html

时间: 2024-10-11 05:39:49

递归的实际业务场景之MySQL 递归查询的相关文章

我的监控世界观(5)--如何在监控中反映业务场景

我在<我的监控世界观>1 ~ 4 中更多的阐述了对于某个监控点的监控.存储.展现.但是在现实世界中,整个世界的联系更像是一个图,每个点可以是某个监控点,而边是他们之间的调用关系或者数据流 举例: webserver –> mysql 对于一个最简单的web 服务, 它可能有两部分组成,webserver 和 mysql存储店铺.商品信息,webserver 服务直接和浏览器用户进行交互.在这样一个业务场景中,webserver 上有的监控点,可能包括单位时间内的UV.PV,而mysql

单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构(转)

转自http://www.php1.cn/Content/DanBiao_60_YiJiLuDengDaShuJuChangJingDe_MySQL_YouHuaHeYunWeiZhiDao_%7C_GaoKeYongJiaGou.html, 更多详细资料请参看原文 此文是根据杨尚刚在[QCON高可用架构群]中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计.前新浪高

秒杀场景下MySQL的低效(转)

秒杀场景下MySQL的低效 2016-01-14 17:12 178人阅读 评论(0) 收藏 举报 最近业务试水电商,接了一个秒杀的活.之前经常看到淘宝的同行们讨论秒杀,讨论电商,这次终于轮到我们自己理论结合实际一次了. ps:进入正文前先说一点个人感受,之前看淘宝的ppt感觉都懂了,等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂,再次验证了"细节是魔鬼"的理论.并且一个人的能力有限,只有大家一起讨论才能想的更周全,更细致.好了,闲话少说,下面进入正文. 一.秒杀带来了什

受教了,memcache比较全面点的介绍,受益匪浅,适用memcached的业务场景有哪些?memcached的cache机制是怎样的?在设计应用时,可以通过Memcached缓存那些内容?

基本问题 1.memcached的基本设置 1)启动Memcache的服务器端 # /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid -d选项是启动一个守护进程, -m是分配给Memcache使用的内存数量,单位是MB,我这里是10MB, -u是运行Memcache的用户,我这里是root, -l是监听的服务器IP地址,如果有多个地址的话,我这里指定了服

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 Posted in MySQL and tagged MySQL, 数据迁移, 方案 on Sep 15, 2015. Viewd 2684 times. 文/温国兵 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁移从库 4.2 场景二 一主一从结构迁移指定库 4.3 场景三 一主一从结构双边迁移指定库 4.4 场景四 一主一从结构完整迁移主从 4.5 场景五 双主结构跨机房迁移 4

整理分布式锁:业务场景&amp;分布式锁家族&amp;实现原理

1.引入业务场景 业务场景一出现: 因为小T刚接手项目,正在吭哧吭哧对熟悉着代码.部署架构.在看代码过程中发现,下单这块代码可能会出现问题,这可是分布式部署的,如果多个用户同时购买同一个商品,就可能导致商品出现 库存超卖 (数据不一致) 现象,对于这种情况代码中并没有做任何控制. 原来一问才知道,以前他们都是售卖的虚拟商品,没啥库存一说,所以当时没有考虑那么多... 这次不一样啊,这次是售卖的实体商品,那就有库存这么一说了,起码要保证不能超过库存设定的数量吧. 小T大眼对着屏幕,屏住呼吸,还好提

基于递归算法,树形结构数据下业务场景,封装解决方法

一.递归算法 1.概念简介 递归算法的核心思想是通过将问题重复分解为同类的或其子问题的方式,从而可以使用统一的解决方式.很多编程语言支持方法或函数自我调用,简单的说,就是在函数或方法体内,自身可以再次调用自身的方法结构. 2.基础案例 这里通过递归的方式,计算阶乘.求和等相关逻辑. public class Demo01 {     public static void main(String[] args) {         int result1 = factorial(5);      

大话业务场景与解决方案-做任务

背景 多数的移动端APP都会有做任务领取奖励的功能模块,这类需求的目的是培养用户使用习惯,提升用户活跃性,用户完成任务获得积分奖励,通过积分兑换商品或者充值话费,微信体现等. 拟定需求场景(如图↓),概要:APP底部导航中新增小任务Tab,点击Tab可查看任务完成进度和领取情况,点击去完成跳转到做任务的业务界面,当用户完成任务并且满足领取条件的时候,任务Tab需要红点提醒用户当前有奖励可领取,用户领取后并且当前没有待领取奖励小红点消失,任务完成进度和领取状态仅保持当天,隔天刷新. 业务分析 在开

wpf企业级开发中的几种常见业务场景

前阵子在公司弄个内部的进销存管理系统,从了解需求.系统设计到编码,大约耗费了两个月时间,后来公司有了其他的安排,这东西就算黄了.顺便吐槽一下,厂里的一些人说话真心不顾别人感受,邮件啥的没一句舒服的.不过以前在别的地方干活都是很多人弄,一直都是按领导的意思办即可,基本上不怎么跟人打交道,不能保持淡定的心态说明还是too young了点,这也算是个历练吧. 弄这个项目,好歹也辛苦了一阵子,另外细节方面感觉自己差不多做到位了,也算尽心了.这里先附几张效果图,接下来将针对几种常见的业务场景抠出一些代码,