我有一个 Informix SQL 查询,它返回一组行。它针对我们一直在开发的网站的新版本进行了轻微修改,我们的质量检查注意到新版本返回了不同的结果。经过调查,我们发现两个查询之间的唯一区别在于返回的字段数量。

FROM、WHERE 和 ORDER BY 子句是相同的,并且 SELECT 部分中的列名不会影响结果。只是字段的数量导致了问题。

有任何想法吗?

有帮助吗?

解决方案 2

Informix SQL 引擎根据我们想要检索的列使用表上的索引。当检索不同的列时,我们使用不同的索引,因此以不同的顺序获得结果。

其他提示

添加 --+ ORDERED join-order 指令允许您每次都以可预测的顺序获取结果,从而解决了这个问题。

这些链接指向该指令如何工作的描述http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1144.htm

使用有序的联接订单指令迫使优化器按照查询从子句中出现的顺序加入表或视图。

SELECT --+ ORDERED
   name, title, salary, dname
FROM dept, job, emp WHERE title = 'clerk' AND loc = 'Palo Alto' 
   AND emp.dno = dept.dno 
   AND emp.job= job.job;

我认为“字段”是指输出数据的行数?根据我的经验,人们将“字段”和“列”用作同义词。鉴于选择列表中的名称没有更改,您可能只得到返回行数的差异。

给定相同的表、输入数据和查询,结果集的大小和内容应该相同,无论查询计划或服务器版本如何。除非您对结果强加顺序,否则结果集的排序可能会有所不同,但这在任何 DBMS 中都是合法的。

如果您获得不同大小的结果集,您可能应该联系 IBM 技术支持。至少有一个结果集是错误的,而且错误的结果总是很严重的。

尽管提示可能有助于提高性能,并且“运行 UPDATE STATISTICS(使用适当的选项集)”的标准建议通常会有所帮助,但当基础数据稳定时,索引的存在或不存在都不会改变结果集。(如果数据发生变化,则需要担心各种问题和复杂性。)

对此我只能想到两种解释:

  1. 正在使用聚合函数,例如 COUNT(DISTINCT column),或者
  2. 选择的附加列来自 OUTER 连接的表

我知道您不希望发布 SQL 和表定义,但这确实使诊断变得困难。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top