编辑:从不太可靠的仅校验和查询更改 我发现了一种方法来做到这一点(在SQL Server 2005中)，这对我来说很好，我可以使用尽可能多的列，因为我需要(通过将它们添加到CHECKSUM()函数)。REVERSE()函数将int类型转换为varchars类型，以使distinct类型更加可靠

SELECT COUNT(DISTINCT (CHECKSUM(DocumentId,DocumentSessionId)) + CHECKSUM(REVERSE(DocumentId),REVERSE(DocumentSessionId)) )
FROM DocumentOutPutItems

这段代码使用distinct on 2参数，并提供特定于这些不同值的行数计数。它在MySQL中为我工作，就像一个魅力。

select DISTINCT DocumentId as i,  DocumentSessionId as s , count(*) 
from DocumentOutputItems   
group by i ,s;

如果您试图提高性能，可以尝试在两个列的散列或连接值上创建持久计算列。

一旦它被持久化，只要列是确定的，并且您使用的是“正常的”数据库设置，就可以对其建立索引和/或在其上创建统计信息。

我相信计算列的不同计数将等效于您的查询。

你的查询没有问题，但你也可以这样做:

WITH internalQuery (Amount)
AS
(
    SELECT (0)
      FROM DocumentOutputItems
  GROUP BY DocumentId, DocumentSessionId
)
SELECT COUNT(*) AS NumberOfDistinctRows
  FROM internalQuery

我有一个类似的问题，但我的查询是一个子查询与比较数据在主查询。喜欢的东西:

Select code, id, title, name 
(select count(distinct col1) from mytable where code = a.code and length(title) >0)
from mytable a
group by code, id, title, name
--needs distinct over col2 as well as col1

忽略这个问题的复杂性，我意识到我无法用原问题中描述的双子查询将a.code的值获取到子查询中

Select count(1) from (select distinct col1, col2 from mytable where code = a.code...)
--this doesn't work because the sub-query doesn't know what "a" is

所以最后我发现我可以作弊，把这些列合并起来:

Select count(distinct(col1 || col2)) from mytable where code = a.code...

这就是最终成功的方法

如果您使用的是固定长度的数据类型，则可以将其转换为二进制，从而非常容易和快速地完成此操作。假设documententid和DocumentSessionId都是int，因此都是4字节长…

SELECT COUNT(DISTINCT CAST(DocumentId as binary(4)) + CAST(DocumentSessionId as binary(4)))
FROM DocumentOutputItems

My specific problem required me to divide a SUM by the COUNT of the distinct combination of various foreign keys and a date field, grouping by another foreign key and occasionally filtering by certain values or keys. The table is very large, and using a sub-query dramatically increased the query time. And due to the complexity, statistics simply wasn't a viable option. The CHECKSUM solution was also far too slow in its conversion, particularly as a result of the various data types, and I couldn't risk its unreliability.

然而，使用上述解决方案几乎没有增加查询时间(与简单使用SUM相比)，并且应该是完全可靠的!它应该能够帮助其他处于类似情况的人，所以我把它贴在这里。