Questions tagged «except»

EXCEPT逻辑运算的用法和语义

4
轻松显示两个表或查询之间不同的行
假设您有两个应该具有/返回相同数据的不同表/查询。您要验证这一点。像下面的示例一样，比较每个列的简单方法是显示每个表中所有不匹配的行吗？假设表中有30列，其中许多是可空的。 当没有PK或每个PK可能有重复项时，仅在PK列上进行联接是不够的，并且必须使用30个可以正确处理NULL的联接条件以及讨厌的WHERE条件进行FULL JOIN排除匹配的行。 通常，当我针对未清理或未完全理解的数据编写新查询时，问题最严重，并且逻辑上可用的PK的可能性极低。我用两种不同的方法来解决问题，然后比较它们的结果，这些差异突出了我不知道的数据中的特殊情况。 结果需要如下所示： Which Col1 Col2 Col3 ... Col30 ------ ------ ------ ------ ------ TableA Cat 27 86 -- mismatch TableB Cat 27 105 -- mismatch TableB Cat 27 87 -- mismatch 2 TableA Cat 128 92 -- no corresponding row TableB Lizard 83 NULL -- no corresponding …
1
不应该避免吗？
在某些SQL Server开发人员中，普遍认为这NOT IN非常慢，应该重写查询以使它们返回相同的结果，但不要使用“ evil”关键字。（示例）。 这有什么道理吗？ 例如，是否存在SQL Server（哪个版本？）中的一些已知错误，该错误导致使用的查询的NOT IN执行计划比使用 一个LEFT JOIN结合了NULL支票或 (SELECT COUNT(*) ...) = 0在WHERE条款中？
5
SQL Server链接服务器性能：为什么远程查询如此昂贵？
我有两个通过链接服务器连接的数据库服务器。两者都是SQL Server 2008R2数据库，并且链接的服务器连接是使用当前登录名的安全上下文通过常规的“ SQL Server”链接建立的。链接的服务器都位于同一数据中心中，因此连接不成问题。 我使用以下查询来检查列的哪些值identifier可远程使用，但不能在本地使用。 SELECT identifier FROM LinkedServer.RemoteDb.schema.[TableName] EXCEPT SELECT DISTINCT identifier FROM LocalDb.schema.[TableName] 在两个表上，列上的都是非聚集索引identifier。本地大约有260万行，远程只有54行。但是，在查看查询计划时，70％的执行时间专用于“执行远程查询”。此外，在研究完整的查询计划时，将使用估计的本地行数1代替2695380（这是仅选择后面的查询时的估计行数EXCEPT）。 当执行此查询时，确实需要很长时间。 这让我感到奇怪：这是为什么？估算是“正确”的吗？还是在链接服务器上进行远程查询真的那么昂贵？
4
相互验证两个表的快速方法
我们正在执行ETL流程。说完所有的话，有一堆表应该是相同的。验证那些表（在两个不同服务器上）实际上是否相同的最快方法是什么。我在说模式和数据。 我可以像在单个文件或文件组上一样对表进行哈希运算吗？可以相互比较。我们有Red-Gate数据比较，但是由于有问题的表包含数百万行，因此我希望每个表都具有更高的性能。 一种吸引我的方法是对联合声明的创造性使用。但是，如果可能的话，我想进一步探讨一下哈希概念。 发布答复更新 对于任何未来的参观者……这就是我最终采取的确切方法。效果很好，我们正在每个数据库中的每个表上执行此操作。感谢下面的回答为我指出了正确的方向。 CREATE PROCEDURE [dbo].[usp_DatabaseValidation] @TableName varchar(50) AS BEGIN SET NOCOUNT ON; -- parameter = if no table name was passed do them all, otherwise just check the one -- create a temp table that lists all tables in target database CREATE TABLE #ChkSumTargetTables ([fullname] varchar(250), [name] …
2
在SQL中比较两个大型数据集的有效方法
目前，我正在比较两个包含唯一StoreKey/ProductKey组合的数据集。 第一个数据集具有StoreKey/ProductKey2012年1月开始至2014年5月结束之间的唯一销售组合（结果= 45万行）。第二个数据集具有独特的StoreKey/ProductKey组合，从2014年6月开始销售到今天（结果= 190K行）。 我正在寻找StoreKey/ProductKey第二组中的组合，但不在第一组中-即从6月初开始销售的新产品。 到目前为止，我已经将这两个数据集转储到了临时表中，在两个键上都为这两个表创建了索引，并使用该EXCEPT语句查找了唯一项。 比较这么大的数据集最有效的方法是什么？有没有更有效的方式进行这种大型比较？
1
EXCEPT运算符背后的算法是什么？
在SQL Server的幕后，Except运算符如何工作的内部算法是什么？是否在内部对每行进行哈希处理并进行比较？ David Lozinksi进行了一项研究，即SQL：在尚不存在的新记录中插入新记录的最快方法。与下面的结果紧密相关。 假设：我认为Left join最快，因为它只比较1列，而Except花费的时间最长，因为它必须比较All列。 有了这些结果，现在我们的思维是“除了自动且内部对每一行进行哈希处理？”。我看了看执行计划，它确实利用了一些哈希。 背景：我们的团队正在比较两个堆表。表A将不在表B中的行插入到表B中。 堆表（来自旧文本文件系统）没有主键/向导/标识符。一些表具有重复的行，因此我们找到了每一行的哈希，并删除了重复项，并创建了主键标识符。 1）首先，我们运行一个except语句，排除（hash列） select * from TableA Except Select * from TableB, 2）然后我们在HashRowId的两个表之间进行左联接比较 select * FROM dbo.TableA A left join dbo.TableB B on A.RowHash = B.RowHash where B.Hash is null 令人惊讶的是，例外声明插入是最快的。 结果实际上与David Lozinksi的测试结果很接近
3
识别哪些值与表格行不匹配
我希望能够轻松地检查表中不存在查询中提供的唯一标识符。 为了更好地解释，这是我现在要执行的操作，以检查表中不存在列表“ 1、2、3、4”的哪些ID： SELECT * FROM dbo."TABLE" WHERE "ID" IN ('1','2','3','4')，假设该表格不包含ID为2的行。 将结果转储到Excel 在原始列表上运行VLOOKUP，以搜索结果列表中的每个列表值。 任何导致的VLOOKUP都#N/A位于表中未出现的值上。 我在想必须有一种更好的方法来做到这一点。理想情况下，我正在寻找类似 要检查的列表->在表上查询以检查->列表中的成员不在表中
1
在SQL Server 2012中比较两个大型结果集的最有效方法是什么
当前比较两个大型结果/行集的最有效方法的建议似乎是使用EXCEPT运算符。随着行大小的增加（更改@last值），下面的自包含SQL脚本效率非常低下。我试图在组合表中查找唯一条目，但没有任何改进。 DECLARE @first AS INT, @step AS INT, @last AS INT; -- This script is comparing two record sets using EXCEPT -- I want to find additions from OLD to NEW -- As number of rows increase performance gets terrible -- I don't have to use two tables. I could …
2
如何用联接替换where子句？
通常，当我看到使用类似以下内容的SQL时： select * from employees where epmloyeeTypeId in (select id from type where name = 'emp') 我将其替换为where： select e.* from employees e inner join type t on t.id=e.epmloyeeTypeId and t.name = 'emp' 如果逆是子句not in（如下面）而不是in子句，是否可以对逆做同样的事情？ INSERT into Subscriptions(ProjectId, RecordTypeCID, NTID, Active, Added, LastUpdate, UpdateBy) SELECT @ProjectId, RecordTypeCID, @NTID, 1, GETDATE(), GETDATE(), …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.