例子
A表
------------------------------
A1 A2 A3 A4 B1 B2 B3 B4 B5
001 002 003 1 701 22 13 14 15
001 002 004 3 702 23 32 54 65
002 003 004 2 403 13 78 96 98B表
------------------------------
A1 A2 A3 C1 C2 C3
001 002 004 601 602 64
001 002 004 701 705 32
002 003 004 401 405 21结果
------------------------------
A1 A2 A3 A4 B1 B2 B3 B4 B5
001 002 004 3 702 23 32 54 65
002 003 004 2 403 13 78 96 98
A表
------------------------------
A1 A2 A3 A4 B1 B2 B3 B4 B5
001 002 003 1 701 22 13 14 15
001 002 004 3 702 23 32 54 65
002 003 004 2 403 13 78 96 98B表
------------------------------
A1 A2 A3 C1 C2 C3
001 002 004 601 602 64
001 002 004 701 705 32
002 003 004 401 405 21结果
------------------------------
A1 A2 A3 A4 B1 B2 B3 B4 B5
001 002 004 3 702 23 32 54 65
002 003 004 2 403 13 78 96 98
inner join 表B as b
on a.A1=b.A1 and a.A2=b.A2
and a.A3=c.A3
where (b.C3=4) and (a.B1 between b.c1 and b.c2)
select a.* from a,b where a.a1=b.a1 and a.a2=b.a2 and c.a3=b.a3 and b.c3=4 and a.b1 between b.c1 and b.c2楼主给的数据不对，或c3=4的条件给错了
我也是用你的方法但速度不容乐观(数据量比较大)to pbsql(风云)
试了一下速度还行,为何与WangZWang(阿来) 的差别这么大,这两句应该实现的功能是一样的
服务器: 消息 3624，级别 20，状态 1，行 1
Location: recbase.cpp:1375
Expression: m_offBeginVar < m_SizeRec
SPID: 54
Process ID: 636连接中断
我一般还是喜欢用 WangZWang(阿来)的方法关注！
永DBCC CHECKDB 检查以下
而且SQL语句对应其它数量小的操作多是可行的,现问题就是对于大批量数据怎样进行优化上面的语句????
DBCC CHECKDB 检查了吗
看结果有不有分配错误和 一致性错误
=============================================================================
服务器: 消息 8951，级别 16，状态 1，行 1
表错误: 表 'MZXX'（ID 171147655）。索引 'IX_MZXX_NO'（ID 4）中下列行的键缺少或无效:
服务器: 消息 8955，级别 16，状态 1，行 1
数据行（1:49858:8）（由 RID = (1:49858:8) 标识）的索引值为 NO = '338(622'。
服务器: 消息 8952，级别 16，状态 1，行 1
表错误: 数据库 'UB2003'，索引 'IX_MZXX_NO'（ID 171147655）（索引 ID 4）。下列键的键多余或无效:
服务器: 消息 8956，级别 16，状态 1，行 1
索引行（1:50250:18）（其值为 NO = '3388622'）指向由 RID = (1:49858:8) 标识的数据行。
服务器: 消息 2511，级别 16，状态 1，行 1
表错误: 对象 ID 171147655，索引 ID 16。在页 (1:85171) 上的槽 41 和 42 处发生键次序错误。
服务器: 消息 2511，级别 16，状态 1，行 1
表错误: 对象 ID 219147826，索引 ID 15。在页 (1:46482) 上的槽 41 和 42 处发生键次序错误。
检查指定数据库中的所有对象的分配和结构完整性。语法
DBCC CHECKDB
( 'database_name'
[ , NOINDEX
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
} ]
) [ WITH { [ ALL_ERRORMSGS ]
[ , [ NO_INFOMSGS ] ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
] 参数
'database_name'是要对其中的所有对象分配和结构完整性进行检查的数据库。如果未指定，则默认为当前数据库。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。 NOINDEX指定不检查非系统表的非聚集索引。NOINDEX 减少执行总时间，因为它不对用户定义的表的非聚集索引进行检查。NOINDEX 对系统表没有影响，因为 DBCC CHECKDB 总是对所有系统表索引进行检查。REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD 指定 DBCC CHECKDB 修复发现的错误。给定的 database_name 必须在单用户模式下以使用修复选项，它可以是下列值之一。值 描述
REPAIR_ALLOW_DATA_LOSS 执行由 REPAIR_REBUILD 完成的所有修复，包括对行和页进行分配和取消分配以改正分配错误、结构行或页的错误，以及删除已损坏的文本对象。这些修复可能会导致一些数据丢失。修复操作可以在用户事务下完成以允许用户回滚所做的更改。如果回滚修复，则数据库仍会含有错误，应该从备份进行恢复。如果由于所提供修复等级的缘故遗漏某个错误的修复，则将遗漏任何取决于该修复的修复。修复完成后，备份数据库。
REPAIR_FAST 进行小的、不耗时的修复操作，如修复非聚集索引中的附加键。这些修复可以很快完成，并且不会有丢失数据的危险。
REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。
WITH指定有关下列内容的选项：返回错误信息的数量、获得的锁或估计的 tempdb 要求。ALL_ERRORMSGS显示每个对象不受限制的错误数。如果没有指定 ALL_ERRORMSGS，每个对象至多显示 200 个错误信息。按对象 ID 对错误信息进行排序（从 tempdb 中生成的消息除外）。NO_INFOMSGS禁止显示所有信息性消息（严重级别 10）和关于所用空间的报告。 TABLOCK导致 DBCC CHECKDB 获得共享表锁。TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。ESTIMATE ONLY显示估计的 tempdb 空间大小，要运行带有所有其它指定选项的 DBCC CHECKDB 则需要该空间。不执行该检查。PHYSICAL_ONLY仅限于检查页和记录标题物理结构的完整性，以及页对象 ID 和索引 ID 与分配结构之间的一致性。该检查旨在以较低的开销检查数据库的物理一致性，同时还检测会危及用户数据安全的残缺页和常见的硬件故障。PHYSICAL_ONLY 始终意味着 NO_INFOMSGS，并且不能与任何修复选项一起使用。注释
DBCC CHECKDB 对索引视图执行物理一致性检查。只用于向后兼容的 NOINDEX 选项也适用于索引视图上的任何辅助索引。DBCC CHECKDB 是最安全的修复语句，因为它对最多的可能出现的各种错误进行标识和修复。如果只报告数据库中有分配错误，请执行带修复选项的 DBCC CHECKALLOC 以对这些错误进行修复。然而，若要确保正确修复所有错误（包括分配错误），请执行带修复选项的 DBCC CHECKDB，而不要执行带修复选项的 DBCC CHECKALLOC。DBCC CHECKDB 对数据库中所有内容的完整性进行验证。如果当前正在执行或最近已执行 DBCC CHECKDB，则不需要运行 DBCC CHECKALLOC 或 DBCC CHECKTABLE。DBCC CHECKDB 执行同样的检查，仿佛是对数据库中的每个表执行 DBCC CHECKALLOC 语句和 DBCC CHECKTABLE 语句。默认情况下，DBCC CHECKDB 不获取表锁。但它获取架构锁，该锁防止对元数据进行更改，但允许更改数据。获取的架构锁将防止用户得到排它表锁，在生成聚集索引、除去任何索引或截断表时需要排它表锁。 DBCC 语句收集信息，然后扫描日志以查找所做的任何其它更改，并在扫描的结尾将两组信息合并在一起以产生数据的一致视图。 如果指定 TABLOCK 选项，DBCC CHECKDB 将获取共享表锁。这样可允许某些类别的错误有更详细的错误信息，并通过避免使用事务日志数据而将所要求的 tempdb 空间大小降为最低。TABLOCK 选项不阻止日志截断并使命令可以更快地运行。DBCC CHECKDB 对数据库中每个表的 text、ntext 和 image 页的链接和大小及数据库中所有页的分配进行检查。对于数据库中每个表，DBCC CHECKDB 检查其： 索引和数据页是否已正确链接。
索引是否按照正确的顺序排列。
各指针是否一致。
每页上的数据是否均合理。
页面偏移量是否合理。
错误表示数据库中的潜在问题，应该立即改正。默认情况下，DBCC CHECKDB 对对象执行并行检查。并行度由查询处理器自动确定。最大并行度的配置方式与并行查询相同。使用 sp_configure 系统存储过程限制可用于 DBCC 检查的最大处理器数。有关更多信息，请参见 max degree of parallelism 选项。使用跟踪标记 2528 可禁用并行检查。有关更多信息，请参见跟踪标记。结果集
未处理修复语句。数据库需要处于单用户模式下。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
我已关闭所有数据库联系了,只开个了查询分析器,不解呀???请帮助!!!谢谢谢
或T-SQL
alter database 'ub2003' set single_user
注意 REPAIR_REBUILD 可能回丢失数据
REPAIR_REBUILD 不会丢失数据
修复后再DBCC 一次
如不行 则只能用 REPAIR_ALLOW_DATA_LOSS
可能回丢失数据