一次神奇的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分钟的执行，我得到了正确的�
相关文档：
查询速度慢的原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
7、 ......
[code=SQL][/code]
--语 句 功 能
--数据操作
SELECT --从数据库表中检索数据行和列
INSERT --向数据库表添加新数据行
DELETE --从数据库表中删除数据行
UPDATE --更新数据库表中的数据
--数据定义
CREATE TABLE --创建一个数据库表
DROP TABLE --从数据 ......
List<Class1> li = dc.Table_1.Where(item => item.id > 1).Cast<Class1>().ToList();
Table_1 为自动生成类, class1为自定义类,属性名称都是一样的,要能实现上面的语句,必须有几个条件
Table_1 需要继承class1,可以通过partial类来实现
Table_1 属性加override
class1里面的属性要是vir ......
1.多where，少having
where用来过滤行，having用来过滤组
2.多union all，少union
union删除了重复的行，因此花费了一些时间
3.多Exists，少in
Exists只检查存在性，性能比in强很多，有些朋友不会用Exists，就举个例子
例，想要得到有电话号码的人的基本信息，table2有冗余信息
select * from table1;--(id,n ......
USE [sfaecrm]
GO
/****** 对象: StoredProcedure [dbo].[proc_insert] 脚本日期: 05/29/2009 06:16:07 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER proc [dbo].[proc_insert] (@tablename varchar(256))
as
begin
set ......
