MYSQL 递归？
=====================
表： t_node
node_id int
node_name varchar2(45)
parent_id int
select * from t_node;
递归开始：
1. 向下查询：查找指定组下的所有分组 ( 不包括本身 )
select t2.node_id ,t2.node_name,t2.parent_id
from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 );
分析：黑色部分为要查的组 id:0
结果：
2. 向下查询：查找指定组下的所有分组 ( 包括本身 )
select t2.node_id ,t2.node_name,t2.parent_id
from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 )
union select t3.node_id ,t3.node_name,t3.parent_id from t_node t3 where t3.node_id= 0 ;
分析：黑色部分为要查的组 id:0
结果：
3. 向上查询：查找该组的所有父组
注意：发现一个问题，白马查不到。
上面的查询只能查 3 级，
转自：
分类表是一种典型的层次化关系的表，从数据库设计工作的角度看，让每个分类记录的 parentId 字段指向它们父分类的 Id即可。
把层次关系转化为数据表并不困难，而且层次还相对比较清晰，但在这种表面现象的背后还有许多难题在等待着用户解决。比如，我们无法只用一个简单的 SELECT 就把指定分类的父分类或者子分类全部查询出来，而必须通过多次查询才能解决这个问题（或者一次查出后，用程序来进行处理）。
事实上，数据库设计和 SQL 编程有着千丝万缕的联系，很难将他们完全区分开来，再者，如果 SQL 不足以把想要查询的数据从数据表里提取出来，那么，想拿出一个优秀的数据为设计方案就只能是一句空谈。
想要通过数据表去管理和使用层次关系，得解决很多难题，而这些难题几乎都与 SQL 语言不能递归查询这一事实有关。以分类表为例：
1 、只用一个查询就把指定分类的所有父分类全部查出来是不可能的
2 、把完整的数据表还原为层次关系（树状）也是一个难点，还是必须执行多次 SQL 才能完成。
3 、把指定分类下所有子分类全部查询出来
4 、设计时，一个分类不能有两个父分类（例如： sql 语言既能够放在 database 分类中，但好象放在 programming 分类下也行，因此，如果 sql 语言有两个父分类仿佛才是合理的）
5 、层次关系最担心 的是留下循环引用隐患（比如手工删除数据或者添加数据时，很容易导致第 4 条的情况发生，数据库层次断链或者重复等）
虽然有这些存在的问题，但并非不可解决，而从上面这些难点来说，层次关系往往会导致即使是一个相对简单的问题也需要很多条 SQL 查询才能得出答案，而且整个过程都相当慢。如果不使用层次关系（或者使用有限的层次关系），上述问题即都可以避免。如果必须使用多级的层次关系，增加一些数据列或数据表来提供更多关于层次关系的信息，将有助于层次关系的解决方案变得简单一些。
从范式的标准来说，冗余是不对的，它会导致存储空间不必要的浪费，增加数据库内部管理工作的负担，但为了提高应用程序的执行效率，冗余反而是一种相当简明的解决方案，因此，数据库设计其实是一件多方妥协和折中的事。在数据库领域，通往同一个目标的道路往往有好多条，选择其中的任意一条，都意味着作出了这样或那样的妥协。做出什么样的妥协最有利这往往取决于数据库的具体使用情况：什么类型的查询发生的最为频繁？数据需不需要频繁修改？
MYSQL 递归操作