创建一
在很长一培明段时间内，Pos360问答tgreSQL都被认为是MySQL的替代品。但是，在那沿地推冷解饭鸡段时间里，根本没有办法使他达到MySQL所能达到的水平。最近几年里，亲正这些问题都无法解决，并且产生了许多有趣的工具来弥补PG。我们在Disqus中使用了两个Slony和pgbouncer。Slony让我们可小顾突汉答段题她响以复制数据（有时候也可以分有克独哥凯远区），而pgbounce损历效将r为我们解决了保持链接和却孙通失连接池的问题。
另外，让我们看看他们的语言：我这个岩速怀打待独头息西星期很高兴能够学会如何在PGSQL8.4中使用递归查询，他们实在太强大了。这就是我这篇取它带拿问续文章所真正想要和大家讨论的东西。MySQL让我们可以工作，并且工作的很好，但你只能在引擎的结构内完成。虽然在PG中依然如此，但你有了更多的选择。因此载衣依肥即，我想讲讲树的线索化的问题。
大家都知道Disqus不仅仅是最大的Django网站（我们每个月有近100万的访灯认行问量），同时，他也是他也是一个最大的网上评毛优德象论系统。我们为上千个网站提供了许多功能，最基本的就是评论作为树状结构的线索化队士。
PostgreSQL提供了许多个关于线索化的解决方案。最常用的（也常粉是最高效的）方法就是改良版的前序遍历。简单的说，他增加了一个左序，一个右序，他们会在你添加评论时被更新。我们还有另一个制映住有字饭员标准的方法（Reddit使用的很欢乐），那就是“取出所有的东西，然后在内存中完成操作”。实际上，不仅仅只有Reddit这样做。
继续看看PGSQL为我们提供的东西，我们还可以找到两个选项（最低在8.4版本）。其中一个是使用PG的内建模块称为ltree。他允许你将一个节点的完整路径（所有父结点）存储下来，同时允许你通过标准的sql语句查询他们。当你需要按照“最早发布”排序的时候，它会非常有用，因为这样以来，就变为了简单的按照“ltree——column”排序。然而，和大部分时候一样，Disqus的情况没有这么简单。
我们的第二个解决方案就是递归查询。他花了我很长一段时间来理解他是怎么工作的，但是当我理解后，我被他的能力深深的吸引了。Postgre提供了许多MySQL所没有的特性，比如over()修饰符。他们真的表现的非常好。
让我们继续深入我们的问题，这会是一个大问题。现在，Disqus和Reddit处理多线程的方法一样，都是和网上其他的解决方案一样，非常的简陋。我说的是简陋不是说代码写的不好，而是他的优化没有做到他应该做到的。直到某些人（就是你，Obama同学）开始使用这个程序，并且所有人都想回复他的话，我们才发现出问题了。我们再一次想到了Django（即使他们越来越大）并且通过业务逻辑将他们分组。
自从8.4开始，我们就可以使用递归查询来解决这个问题（在许多情况下我们已经自己开始这么做了，虽然会有点复杂）这个相当的简单。
因此，让我们一个基本的例子。我们有一个的评论模型，它看起来有点像这样：
create table comments ( id SERIAL PRIMARY KEY, message VARCHAR, author VARCHAR, parent_id INTEGER REFERENCES comments(id) ); insert into comments (message, author, parent_id) values ('This thread is really cool!', 'David', NULL), ('Ya David, we love it!', 'Jason', 1), ('I agree David!', 'Daniel', 1), ('gift Jason', 'Anton', 2), ('Very interesting post!', 'thedz', NULL), ('You sir, are wrong', 'Chris', 5), ('Agreed', 'G', 5), ('Fo sho, Yall', 'Mac', 5);
我们现在所做的，是建立一个基本的评价模型。我们的消息，笔者父评论（这是可选的）。现在，让我们来学习如何使用递归查询可以轻松地重新订购本datd中，由id升序排序。
WITH RECURSIVE cte (id, message, author, path, parent_id, depth) AS ( SELECT id, message, author, array[id] AS path, parent_id, 1 AS depth FROM comments WHERE parent_id IS NULL UNION ALL SELECT ***.id, ssage, ***.author, cte.path || ***.id, comments.parent_id, cte.depth + 1 AS depth FROM comments JOIN cte ON comments.parent_id = cte.id ) SELECT id, message, author, path, depth FROM cte ORDER BY path;
很甜蜜吧？哦，等等，有困惑？所以我一直在寻找的查询更复杂的是一大堆惊人的bug.
pgexperts为我们指向正确的道路。
现在，我不会钻到太多，因为有更好的教程，在此模式中处理递归查询，但我们完成了我们的结果。
我们要处理一个巨大信息集，并且有些评论有将近几千个回复。如果99%的评论都只有100个回复，那么将他们放入内存中并不是什么问题，但当他们开始增加时，我们最终会浪费很多时间。PGSQL中的递归查询可以让我们很简单的把这项工作交给数据库（有时候他们处理的比我们快的多），并且给我们节省了很多花费在网络传播和web处理的时间和资源。
有一个例子可以让你更直观的理解他是多么的高效，我们曾经见过仅在大型数据库的SQL处理时间这一项上（返回25个结果，而不是1000个）就将近节省了500%的时间。这甚至没有包括我们在程序级上的花费。是的，没错，这些SQL语句仅在数据库层上就比其他数据库快5倍
总而言之，作为一个MySQL的拥护者，我对Disqus使用PostgreSQL所达到的性能，规模，以及灵活性表示十分震惊。我十分期待去发现通过这个平台我们还能做什么，去寻找还在等待我们的挑战。
sql语句实现递归查询所有节点,mysql和oracle都能用的
首先说一下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 表中，t.id 等于上面查询出的结果集的数据。FIND_IN_SET(A,B)是MYSQL的函数。意思是查找在B集合中有A的数据。相当于In
select t.* from t_discretionary_power t where FIND_IN_SET(t.id,queryChildrenPowerInfo('fa2528924c7e9168014c9bedfe04039c'))
Mysql中怎么进行递归查询?
概念说不一定理解，给你一个例子你自己参悟。
SELECT TEACHER
FROM C AS X
WHERE UNIQUE(SELECT TEACHER
FROM C AS Y
WHERE Y.TEACHER=X.TEACHER);
