通常来说，SQL语言进行的都是无序操作。想要进行有序的处理，比如比较一个序列的前后项，必须要使用游标。但是，在有些场合下，可采用另一种方法，不用游标，一样能处理有序的信息，这就是不等联接。先看下面一个例子

这样的问题：以下表HISTORY

CREATE TABLE [HISTORY] (

[TheDate] [datetime] NULL ,

[Quantity] [int] NULL

) ON [PRIMARY]

中存储的是一系列的历史数据，例如：

INSERT HISTORY VALUES('2002-01-01 00:00:00.0',11)

GO

INSERT HISTORY VALUES('2002-01-02 00:00:00.0',34)

GO

INSERT HISTORY VALUES('2002-01-03 00:00:00.0',27)

GO

INSERT HISTORY VALUES('2002-01-04 00:00:00.0',43)

GO

现在，我们要查询自起始日期至每一个日期的总量。也就是说，显示这样一个结果集：

TheDate Quantity q_sum

2002-01-01 00:00:00.0 11 11

2002-01-02 00:00:00.0 34 45

2002-01-03 00:00:00.0 27 72

2002-01-04 00:00:00.0 43 115

直观上来讲，我们可以在SELECT * FROM HISTORY ORDER BY TheDate上建一个游标，从第一条开始，每一条，加一次。那换个想法呢？如果我们建立这样一个结果集，让每一个日期限，都对应它当天的数量及所有在它之前的数量记录。那么我们就可以按这个日期分组，对数量进行求和。很显然，一个不等查询就这样形成了。我最初的写法有错误，以下是经 BuildIt 修改后最终的语句

select l.TheDate,

l.quantity,

sum(r.quantity) as q_sum

from HISTORY l

join HISTORY r

on l.TheDate >= r.TheDate

group by l.TheDate, l.quantity

order by l.TheDate

不等联接本身就不是一一对应，它的对应关系和顺序有着密切的关系。这也就是我们能够拿它来进行有序操作的原因。再给一个很自然的例子：

SELECT L.I, SUM(R.I)

FROM N L

JOIN N R

ON L.I >=R.I

GROUP BY L.I

表N只有一个整型列I，保存自然数列。所以，没什么神秘，这就是求自然数列的和。这里SUM(R.I)表示自然数列N从零至I的累加和，比前面的那个问题还要简单。不过显然这不是不等联接发挥威力的地方，因为它会形成一个巨大的三角形数据集，就像下面这样

1 1

2 1

2 2

3 1

3 2

3 3

...

当我对十六位整型的列表执行这个查询时，我的AthlonXP1700+/256MDDR的机器足足运行了近三十分钟，当我写下现在这段文字时，它返回了一个数据溢出错误。显然，对于这个查询，即使是十六位整数的列表，也太大了。我的建议是，仅当结果集无法用公式表达时，使用不等联接。像这个累加，我们早已有了成熟的公式，何必再让计算机傻算呢？用下面这个语句

SELECT I, ((1+I)*I)/2

FROM N

相比老老实实地累加，速度奇快。发现数据溢出时，连一秒钟都不到，可这台计算机就是想不到用这个方法，唉……

传说数学界一代宗师高斯小学的时候，他老师考过他这个问题。所以几乎所有的中国小学生，都被老师用这道题折磨过。好像老师们的目的就在于告诉我们，我们的智商比不上高斯。可我压根就没想和人家比啊……

上大学时，教我们第一本《数学分析》的范先令老师说计算机是傻子，我当时只是觉得好玩而已，今天算是见识了，看来在归纳总结的能力方面，计算机也就是我小学时的水平，永远也赶不上高斯上小学那会儿了。

不过，这种东西用于公式难以表达的地方，还是有意义的。比如我的一个朋友用不等联接写过一个素数筛子，很有趣。它虽说不会比我们用过程化的代码写出来的程序效率更高，但却能把筛法根本的精要表达的清清楚楚，也许以后我们研究数论，会用的上这种SQL风格的表示法呢。这位朋友教了我很多计算机方面的知识，出于对他的尊重，我不会抄录他的代码。不过这个语句本身并不复杂，相信朋友们想到用联接查询后，都一定写得出来，大家有兴趣的话，自己不妨试试。用它还可以实现其它的一些数列，以后我们再讨论几个。

不等联接还有一个用法，可以用它生成一个序号列，比如

SELECT COUNT(L.AFIELD) AS ID,

L.AFIELD

FROM MYTABLE L

JION MYTABLE R

ON L.AFIELD > R.AFIELD

GROUP BY L.AFIELD

AFIELD字段可以是字符串、日期，当然也可以是数值，反正可排序就行。这东西有点奇技淫巧的味道，数据量太大，就不好玩了，一般还是用物理行号的好，虽说不是SQL标准，但实用啊。这个例子我在MCDBA的复习题中见过（据说这道题考过），不过我的那位朋友自己就做出来过，大家可能也有独立实现过这一方法的吧。

不等查询的有序操作能力，显然来自联接字段的可排序和互异性，所以，最好不要在有重复值的字段上做不等联接（事实上，最好不要在有重复值的字段上做任何联接，除非你非常肯定你在干什么）。等值联接出现数据爆炸就够可怕的了，不等联接要是玩爆了……嘿嘿嘿……

想像一个等值联接中有一对重复值，可能出现两对重复结果。不过要是不等联接，就和重复的位置有关了。因为这是一个三角形，所以出现在最上面还好，要是出现在这个三角形的下部……

不等联接查询，显然是一个有力的工具，但它也是招来麻烦的快捷方式之一。有几个建议，是我的经验：
如果联接会生成很大的“三角形”，就不要用，试试子查询或哪怕游标；

生成的结果集相对于原表越小越好，尽可能地把无用的数据先过滤掉；

用不等联接进行数列计算会表达的很清楚（因为是非过程化的），但通常在效率上它没有什么优势，所以，平时玩玩可以，真用的话最好先考虑好；

还有就是不等联接不要轻易用在多重联接中，否则可能会引起杠杆作用。