在 SQL 中,“不同”是指“不同”。将结果行数从 1 减少到 0
我有一个具有以下结构的 SQL 语句:
select distinct ...
from table1,
(select from table2, table3, table4 where ...)
where ...
order by ...
对于 where 子句中的某些值,该语句在结果集中返回零行。当我删除“distinct”关键字时,它返回一行。我希望在这两种情况下都能看到单个结果行。是否有我不知道的“distinct”关键字的某些属性导致了这种行为?
数据库是Oracle 11g。
I have a SQL statement of the following structure:
select distinct ...
from table1,
(select from table2, table3, table4 where ...)
where ...
order by ...
With certain values in the where clauses, the statement returns zero rows in the result set. When I remove the 'distinct' keyword, it returns a single row. I would expect to see a single result row in both cases. Is there some property of the 'distinct' keyword that I am not aware of and that causes this behavior?
The database is Oracle 11g.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您所描述的不是 DISTINCT 的预期行为。这就是:
所以,如果你所说的情况确实发生了,那么它就是一个错误。但是,您也说这种情况很少发生,这意味着很可能是您的数据和/或环境中的瞬态条件存在某种特殊性,而不是错误。
您需要创建一个可重现的测试用例,原因有两个。在某种程度上,如果没有人,没有人能够调查你的问题。但主要是因为构建测试用例本身就是一项调查:尝试隔离数据和/或环境因素的精确组合通常会产生洞察力,从而得出解决方案。
What you describe is not the expected behaviour of DISTINCT. This is:
So, if what you say is happening really is what is happening then it's a bug. However, you also say it's a rare occurrence which means there is a good chance it is some peculiarity in your data and/or transient conditions in your environment, and not a bug.
You need to create a reproducible test case, for two reasons. Partly, nobody will be able to investigate your problem without one. But mainly because building a test case is an investigation in its own right: attempting to isolate the precise combination of data and/or ambient factors often generates the insight which leads to a solution.
事实证明,其中一个子选择生成的数据集除其他外还包含一行,其中每列均为 NULL。看来这一行以一种不明显的方式影响了 DISTINCT 的评估(至少对我来说)。也许这是由于一些底层的 SQL 优化造成的。在我删除此 NULL 填充行的原因后,问题就消失了,并且该语句按其应有的方式计算结果中的一行。
It turned out that one of the sub-selects resulted in a data set that contained, among others, a row where every column was NULL. It seems that this row influenced the evaluation of the DISTINCT in a non-obvious way (at least to me). Maybe this is due to some under-the-hood SQL optimizations. After I removed the cause of this NULL-filled row, the problem is gone and the statement evaluates to one row in the result as it should.