mysql建立数据表 带父ID和子ID的数据表是怎样建的

id name pri

1 父1 0

2 父2 0

101 子101 1

102 子102 1

201 子201 2

202 子202 2

pri列表示父子关系

0表示最高等级的节点。

1表示这行商品的父节点是1 即id=1的商品

如此类推。。。

根据你的资料，正确的答案应该如下：望采纳

CREATE DEFINER=`root`@`localhost` PROCEDURE `P_updateUd18`(`Param` int(11))

BEGIN

declare Rcount,i,j,k,Rparentid,myId int(11) default 0;

declare Robjname,Robjname23,Robjname45,Robjname67,Robjname89 varchar(9) default "";

select count(id) into Rcount from ud18;

repeat

select id,objname into myId,Robjname from ud18 order by id limit i,1;

set Robjname23=SUBSTRING(Robjname,2,2);

set Robjname45=SUBSTRING(Robjname,4,2);

set Robjname67=SUBSTRING(Robjname,6,2);

set Robjname89=SUBSTRING(Robjname,8,2);

if Robjname89>0 then

set @sql=concat("select id into @abc from ud18 where objname like '",left(Robjname,7),"00","'");

prepare stmt from @sql;

EXECUTE stmt;

set Rparentid=@abc;

update ud18 set parentid=Rparentid where id=myId;

elseif Robjname67>0 then

set @sql=concat("select id into @abc from ud18 where objname like '",left(Robjname,5),"0000","'");

prepare stmt from @sql;

EXECUTE stmt;

set Rparentid=@abc;

update ud18 set parentid=Rparentid where id=myId;

elseif Robjname45>0 then

set @sql=concat("select id into @abc from ud18 where objname like '",left(Robjname,3),"000000","'");

prepare stmt from @sql;

EXECUTE stmt;

set Rparentid=@abc;

update ud18 set parentid=Rparentid where id=myId;

elseif Robjname23>0 then

-- set @sql=concat("select id into @abc from ud18 where objname like '",left(Robjname,1),"00000000","'");

-- prepare stmt from @sql;

-- EXECUTE stmt;

-- set Rparentid=@abc;

update ud18 set parentid=0 where id=myId;

else

set j=0;

end if;

set i=i+1;

until i>Rcount end repeat;

END;

首先说说索引的 优点 ：最大的好处无疑就是提高查询效率。有的索引还能保证数据的唯一性，比如唯一索引。

而它的 坏处 也很明显：索引也是文件，我们在创建索引时，也会创建额外的文件，所以会占用一些硬盘空间。其次，索引也需要维护，我们在增加删除数据的时候，索引也需要去变化维护。当一个表的索引多了以后，资源消耗是很大的，所以必须结合实际业务再去确定给哪些列加索引。

再说说索引的基本结构。一说到这里肯定会脱口而出：B+树！了解B+树前先要了解二叉查找树和二叉平衡树。 二叉查找树 ：左节点比父节点小，右节点比父节点大，所以二叉查找树的中序遍历就是树的各个节点从小到大的排序。 二叉平衡树 ：左右子树高度差不能大于1。B+树就是结合了它们的特点，当然，不一定是二叉树。

为什么要有二叉查找树的特点？？ 因为查找效率快，二分查找在这种结构下，查找效率是很快的。 那为什么要有平衡树的特点呢？ 试想，如果不维护一颗树的平衡性，当插入一些数据后，树的形态有可能变得很极端，比如左子树一个数据没有，而全在右子树上，这种情况下，二分查找和遍历有什么区别呢？而就是因为这些特点需要去维护，所以就有了上面提到的缺点，当索引很多后，反而增加了系统的负担。

接着说B+树。 它的结构如下 ：

可以发现，叶子节点其实是一个 双向循环链表 ，这种结构的好处就是，在范围查询的时候，我只用找到一个数据，就可以直接返回剩余的数据了。比如找小于30的，只用找到30，其余的直接通过叶子节点间的指针就可以找到。再说说其他特点： 数据只存在于叶子节点 。当叶子节点满了，如果再添加数据，就会拆分叶子节点，父节点就多了个子节点。如果父节点的位置也满了，就会扩充高度，就是拆分父节点，如25 50 75拆分成：25为左子树，75为右子树，50变成新的头节点，此时B+树的高度变成了3。它们的扩充的规律如下表，Leaf Page是叶子节点，index Page是非叶子节点。

再说说B树 ，B树相比较B+树，它所有节点都存放数据，所以在查找数据时，B树有可能没到达叶子节点就结束了。再者，B树的叶子节点间不存在指针。

最后说说Hash索引 ，相较于B+树，Hash索引最大的优点就是查找数据快。但是Hash索引最大的问题就是不支持范围查询。试想，如果查询小于30的数据，hash函数是根据数据的值找到其对应的位置，谁又知道小于30的有哪几个数据。而B+树正好相反，范围查询是它的强项。

附录： Hash到底是啥？？ 哈希中文名散列，哈希只是它的音译。 为啥都说Hash快？？ 首先有一块哈希表（散列表），它的数据结构是个数组，一个任意长度的数据通过hash函数都可以变成一个固定长度的数据，叫hash值。然后通过hash值确定在数组中的位置，相同数据的hash值是相同的，所以我们存储一个数据以后，只需O(1)的时间复杂度就可以找到数据。 那hash函数又是啥？？ 算术运算或位运算，很多应用里都有hash函数，但实际运算过程大不一样。这是Java里String的hashCode方法：

publicint hashCode() {

}

还有一个问题，hash函数计算出来的hash值有可能存在碰撞，即两个不同的数据可能存在相同的hash值，在MySQL或其他的应用中，如Java的HashMap等，如果存在碰撞就会以当前数组位置为头节点，转变成一个链表。

说到这里也清楚了为啥Java中引用类型要同时重写hashCode和equals了。两个对象，实例就算一模一样，它们的hash值也不相等， 为啥不相等？？ 默认的Object的hashCode方法会根据对象来计算hash值的，实例相同，但它们还是两个不同的对象啊，所以我们重写hashCode时，最简单的方法就是调用Object的hashCode方法，然后传入该引用类型的属性，让hashCode方法只根据这几个属性来计算，那么实例相同的话，它们的hash值也会相等。等hashCode比较完后，如果相等再比较实例内容，也就是equals，确保不是hash碰撞。

索引的分类

如果我们指定了一个主键，那么这个主键就是主键索引。如果我们没有指定，Mysql就会自动找一个非空的唯一索引当主键。如果没有这种字段，Mysql就会创建一个大小为6字节的自增主键。如果有多个非空的唯一索引，那么就让第一个定义为唯一索引的字段当主键，注意，是第一个定义，而不是建表时出现在前面的。

对于辅助索引来说，它们的B+树结构稍微有点特殊，它们的叶子节点存储的是主键，而不是整个数据。所以在大部分情况下，使用辅助索引查找数据，需要二次查找。但并不是所有情况都需要二次查找。比如查找的数据正好就是当前索引字段的值，那么直接返回就行。这里提一句，B+树的key就是对应索引字段的内容。

而辅助索引又有一些分类：唯一索引：不能出现重复的值，也算一种约束。普通索引：可以重复、可以为空，一般就是查询时用到。前缀索引：只适用于字符串类型数据，对字符串前几个字符创建索引。全文索引：作用是检测大文本数据中某个关键字，这也是搜索引擎的一种技术。

注意，聚集索引、非聚集索引和前面几个索引的分类并不是一个层面上的。上面的几个分类是从索引的作用来分析的。聚集、非聚集索引是从索引文件上区分的。主键索引就属于聚集索引，即索引和数据存放在一起，叶子节点存放的就是数据。数据表的idb文件就是存放该表的索引和数据。

辅助索引属于非聚集索引，说到这也就明白了。索引和数据不存放在一起的就是非聚集索引。在MYISAM引擎中，数据表的MYI文件包含了表的索引， 该表的 叶子节点存储索引和索引对应数据的指针，指向MYD文件的数据。

索引的几点使用经验

经常被查询的字段；经常作为条件查询的字段；经常用于外键连接或普通的连表查询时进行相等比较字段；不为null的字段；如果是多条件查询，最好创建联合索引，因为联合索引只有一个索引文件。

经常被更新的字段、不经常被查询的字段、存在相同功能的字段

第一篇文章，从某个同行问我的问题开始。

他的问题大概是这样的：自己已经用Oracle的Start withConnect By实现了树的递归查询，但是现在要求变了，要用MYSQL也实现相同的递归查询树的功能。这个功能是我从以前从未使用到过的，于是，我上网查询、找了一些资料开始做了起来。我喜欢这种“自己每次在帮助了别人的同时又提高了自己”的进步，因为，我始终相信，会分享、会帮助别人的人注定海纳百川。到最后，功夫不多，总算给他提供了解决方案。我的解决方案只是针对同一个表，两个表只需要在方法里增加两个表的连接条件即可。

下面是我的一些MYSQL最终代码可供解决参考：

创建表nodelist：

CREATE TABLE nodelist( id INT PRIMARY KEY, //本节点ID。 nodename VARCHAR(20), //节点名称，为方便辨别而已。 pid INT //父节点。 );

插入表测试数据：

Insert INTO nodelist VALUES(1,'A',null); //父节点为，即根节点。Insert INTO nodelist VALUES(2,'B',1); Insert INTO nodelist VALUES(3,'C',1); Insert INTO nodelist VALUES(4,'D',2); Insert INTO nodelist VALUES(5,'E',3); Insert INTO nodelist VALUES(6,'F',3); Insert INTO nodelist VALUES(7,'G',5); Insert INTO nodelist VALUES(8,'H',7); Insert INTO nodelist VALUES(9,'I',8); Insert INTO nodelist VALUES(10,'J',8);

创建函数getChildList()：

CREATE FUNCTION `getChildList`(rootId INT) //rootId为你要查询的节点。 RETURNS VARCHAR(1000) BEGIN DECLARE pTemp VARCHAR(1000); DECLARE cTemp VARCHAR(1000); //两个临时变量 SET pTemp = '$'; SET cTemp =cast(rootId as CHAR); //把rootId强制转换为字符。 WHILE cTemp is not null DO SET pTemp = concat(pTemp,',',cTemp); //把所有节点连接成字符串。 SELECT group_concat(id) INTO cTemp FROM nodelist WHERE FIND_IN_SET(pid,cTemp)>0; // FIND_IN_SET(str,strlist)的方法网上大把不解释。 END WHILE; RETURN pTemp; END

执行方法getChildList(1)：

SELECT getChildList(1);

运行结果如下图：

查询节点为“3”下的所有节点：

SELECT FROM nodelist WHERE FIND_IN_SET(id, getChildList(3));

运行结果如下图：

首先说一下Oracle的递归查询，相信大部分人都知道很简单。无非start with connect by 函数。下面是从pId向子节点递归查询的例子，unId是数据库表中的主键。

如果是从子节点递归到父节点查询，就把start with 换成unid，prior左右对换

下面再讲MySql 的递归查询方式。MySql没有Oracle的强大功能，虽然都是同一个公司的产品。所以只能靠自己写。有很多方法，用sql去循环查询，或者写存储过程，我这里只提供一种。就是新建一个function函数。

表结构不说了，无非就是 Id ，pId，其他列。下面是创建一个递归查询子节点的函数

DROP FUNCTION IF EXISTS queryChildrenPowerInfo;

CREATE FUNCTION `queryChildrenPowerInfo` (powerId VARCHAR(2000))

RETURNS VARCHAR(2000)

BEGIN

DECLARE sTemp VARCHAR(2000);

DECLARE sTempChd VARCHAR(2000);

SET sTemp = '$';

SET sTempChd = cast(powerId as CHAR);

WHILE sTempChd is not NULL DO

SET sTemp = CONCAT(sTemp, ',', sTempChd);

SELECT group_concat(id) INTO sTempChd FROM t_discretionary_power where FIND_IN_SET(pId,sTempChd)>0;

END WHILE;

return sTemp;

END

调用的时候：select  queryChildrenPowerInfo("fa2528924c7e9168014c9bedfe04039c"); 该语句会返回Id和父Id等于传入参数powerId的一个字符串，中间有逗号隔开如图

下面这句代码的意思是，查询出 t_discretionary_power  表中，tid 等于上面查询出的结果集的数据。FIND_IN_SET(A,B)是MYSQL的函数。意思是查找在B集合中有A的数据。相当于In

select t from t_discretionary_power  t where FIND_IN_SET(tid,queryChildrenPowerInfo('fa2528924c7e9168014c9bedfe04039c'))

文中使用公司部门结构树作为栗子，要在mysql中存储这个公司部门结构树

邻接表想必大家都不陌生吧，用邻接表的关键是，在每个节点存储他的父节点的id。

在每一个部门信息中都存储了他的父节点id，parent_id字段

导入数据的过程就不说了，直接来看下数据吧：

这里使用常用的几种查询方式来看下这种方案的查询

可以通过parent_id做查询条件，可以快速查询到一个部门的直属下级部门

通过部门信息中的parent_id去查相应的父节点信息就可以快速实现

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准父节点的id，组织部门变更时，也直接变更父id就好了，删除时候，看自己业务是否需要删除子节点这几种情况，

路径标的要点，就是每个节点存储根节点到该节点的路径，其实我觉得和别的几种方案可以共用

在每一个部门信息中都存储了他完整的路径，path字段

导入数据的过程就不说了，直接来看下数据吧：

使用路径表，通过path这个字段查询起来是比较困难的，一般都需要使用like，CONCAT函数、REPLACE函数等做字符串的处理逻辑，查询起来比较复杂，这里不做展示了，线上服务不建议使用这种方式，查询效率低会影响到服务性能，一般建议和邻接表方式统一使用，同时添加parent_id和path字段，parent_id用来查询，path用来查看节点完整的路径

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准路径就好，组织部门变更时，也直接找准路径就好，删除时候，看自己业务是否需要删除子节点这几种情况，

Closure Table，百度直译过来叫闭合表，大多数人叫做闭包表，这种方案的要点是存储公司部门信息主表中，不存储节点关系的数据，使用另一张关系表来存储节点之间的关系，其中包含了任何两个有关系（上下级）节点的关联信息

公司部门信息主表，只需要存储部门的本身信息

主要包括三个字段

要点就是关系表的一条记录是一个上级节点、下级节点、与他们之间的路径距离。拿部门结构图来举例子

总公司-企划部的关系数据是：

总公司-大区A的关系数据是：

关系表中存储所有的节点路径信息，还用distance表示路径的距离，需要把树形结构中每两个节点之间的路径信息都维护进来。

数据存储的过程就拿导入总公司-门店A的过程做个示例。主表的数据存储就不说，说下关系中，存储部门结构的路径信息，总公司-门店A总共包含以下几条路径：

看到了么，是存储了所有总公司-门店A之间的路径信息

这里使用常用的几种查询方式来看下这种方案的查询

这种数据存储结构下，更新数据比较麻烦，因为他存储了两节点直接所有路径信息（包括中间节点的）

单表自身关联查询，关联条件就是父节点pcode和code相等，查询字段包含pcode和sorce，将查询结果作为新表按pcode分组，用group by，查询字段是count记录数，这样就获取pcode的节点值，这是整体思路

以上就是关于mysql建立数据表 带父ID和子ID的数据表是怎样建的全部的内容，包括:mysql建立数据表 带父ID和子ID的数据表是怎样建的、mysql使用游标遍历数据进行批量针对性更新数据，急求mysql大神解答、MySQL——关于索引的总结等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！