一次神奇的SQL 错误调试经历

上周接到一个奇怪的bug，一个曾经运行得很好的存储过程突然产生了错误的结果。

负责维护的兄弟们很负责任的对错误进行了跟踪，并把错误定位一个如下的语句：

 

SELECT *

into SomeTable

FROM A join B on A.id=B.id

         join C on A.id=C.id

 

他们发现从SomeTable做查询的时候，出来的结果比实际结果要大若干倍，挺齐整的，4倍或者2倍。

我的第一个感觉是JOIN出问题了，必然是形成了多对多的JOIN，比如A里面有两行ID一样，B也有两行ID一样，结果表就会出现4行一样的，得到一个4倍的结果，同样的道理，如果A里有一行，B里有2行，结果就是2倍了。

 

于是我让他们把SomeTable做成一个文本文件传给我，嗯，300M的一个文件，BCP到数据库里，SELECT了一把，把出问题的那个ID抓出来，果然看到几个重复的行。确切的说看到几列几乎一样的行。

 

于是我就兴冲冲的给他们说，检察一下B和C上面的ID是否是unique的。

 

结果很快返回，说，是unique的。

 

这下我就傻眼了，这怎么可能呢。重新仔细的看了便上次查处的结果，发现原本以为重复的行，竟然不是完全相同的，嗯，有一列是不同的，而这一列正式B.ID。请注意，这些行在A.id上是一样的。

 

这是一个惊人的发现，我通过A JOIN B JOIN C出来的结果居然不满足JION的条件，这彻底颠覆了多年学习的关系数据库知识。

 

毫无疑问，这是SQL Server的一个bug。然而如何建一个最小的数据集合来重现这个bug成了新的挑战。因为ABC三个表加起来有200G，而如果我删掉一些看起来不相关的行，错误就消失了。我也试图将ABC的JION分成两步来做，

比如：

select *

FROM

(SELECT * from A JOIN B) AS D

   JOIN C ON...

结果仍然错误。

但是如果再进一步，

SElect * into temp from A join B...

Select * FROM temp join C...

错误消失了。

 

黔驴技穷之后，俺只好求救于SQl server的技术支持。刚开始发了封信，问有没有人遇到过这种问题，ABC 交出的结果包含不满足JOIN条件的行。结果一个小子居然说，这个问题太基本，这种情况根本不可能出现。 Sigh，大叔我也不是新手，简单问题还需要劳烦您老人家吗。

 

于是再仔细的描述问题，终于出了一个比较靠谱的哥们，让我把执行计划发给他看看。再然后另外一个哥们说可能是并发引起的问题，建议我用MAXDOP来限制参与执行的CPU个数。于是，我在原来的SQL后面加了个OPTION MAXDOP=1，果然经过7分钟的执行，我得到了正确的结果。

 

然后给Sql server开bug，居然已经有hotfix了，估计我们不是第一个踩到雷的人。呵呵。

 

这个故事告诉我们，看问题要仔细，不要被自己的知识所蒙蔽，然后描述问题要清楚，要找正确的人问问题。