1

让我们有一个简单的表格：

CREATE TABLE dbo.test
(
    c1  INT
)

INSERT INTO test (c1) VALUES (1)
INSERT INTO test (c1) VALUES (2)
INSERT INTO test (c1) VALUES (3)

接下来计算一些 SUM：

SELECT SUM(t1.c1) FROM test AS t1 , test AS t2
WHERE t2.c1 = 1

输出为： 6 。简单易行。

但是如果我运行：

SELECT SUM(t1.c1), * FROM test AS t1 , test AS t2
WHERE t2.c1 = 1

输出是：

6   2   2
6   2   3
6   2   1
6   3   2
6   3   3
6   3   1
6   1   2
6   1   3
6   1   1

我的问题是：为什么第二个输出与 WHERE 子句中的条件不匹配？

4

1 回答 1

6

看起来 Sybase 实现了它自己的扩展GROUP BY：

通过以下扩展，Sybase 取消了对可以在包含 group by 的查询的选择列表中包含或省略的内容的限制。

  • 选择列表中的列不限于分组列和与向量聚合一起使用的列。

  • group by 指定的列不限于选择列表中的那些非聚合列。

然而，扩展的结果并不总是直观的：

当您在包含 where 子句或连接的复杂查询中使用 Transact-SQL 扩展时，结果可能会变得更加难以理解。

这与您的问题有什么关系？

但是，Adaptive Server 处理 select列表和where子句中额外列的方式可能看起来是矛盾的。例如：

select type, advance, avg(price) 
from titles 
where advance > 5000
group by type

type           advance
-------------  ---------  --------
business        5,000.00      2.99
business        5,000.00      2.99
business       10,125.00      2.99
business        5,000.00      2.99
mod_cook            0.00      2.99
mod_cook       15,000.00      2.99
popular_comp    7,000.00     21.48
popular_comp    8,000.00     21.48
popular_comp        NULL     21.48
psychology      7,000.00     14.30
psychology      2,275.00     14.30
psychology      6,000.00     14.30
psychology      2,000.00     14.30
psychology      4,000.00     14.30
trad_cook       7,000.00     17.97
trad_cook       4,000.00     17.97
trad_cook       8,000.00     17.97



(17 rows affected)

where当您查看高级（扩展）列的结果时，似乎查询忽略了该子句。Adaptive Server 仍然只使用满足该子句的那些行来计算向量聚合where，但它也会显示select列表中包含的任何扩展列的所有行。要进一步限制结果中的这些行，您必须使用having子句。

因此，为了给您预期的结果，Sybase 应该允许您执行以下操作：

SELECT SUM(t1.c1), * FROM test AS t1 , test AS t2
WHERE t2.c1 = 1
HAVING t2.c1 = 1

WHERE将从总数中排除结果SUM；将HAVING隐藏不符合条件的记录。

令人困惑，不是吗？

相反，您最好编写查询以便它不需要 Sybase 的GROUP BY扩展。

于 2013-03-05T18:32:21.720 回答