在任何情况下,我都不喜欢 Co-related Sub 查询。从评论中我看到这是针对 INFORMIX 而不是针对 SQL,因此我建议将 JOIN 与嵌套选择一起用作首选。这样做的好处是这些是编写查询的非常原生的方式,并且您可以期望数据库优化器使用索引(如果可用)提出良好的执行计划。在 SQL 中,如果我的表不在数百万行中,我会选择 CTE。我假设您在表上有适当的索引。如果不确定您在表上有以下索引。
注意索引中列的顺序及其 ASC/DESC 顺序。
CREATE CLUSTER INDEX IDXc_alt6sal
ON alt6sal ( meg_code ASC,
sal_year DESC,
sal_mon DESC,
emp_num ASC
)
CREATE INDEX IDXnc_alt6sal
ON alt6sal ( meg_code ASC,
sal_year DESC,
sal_mon DESC,
emp_num ASC
) INCLUDE (meg,currency)
现在测试下面的查询。请注意,当我使用实际表时,我在所有选择中添加了“meg_code IN (1, 2)”条件。即使在嵌套的选择语句中,也允许查询减少结果集中需要的行数。另请注意,查询中在 Where 和 JOIN 条件中提到的列与索引中的列顺序匹配。
我留给你尝试的一件事是
“meg_cod=1 或 meg_cod=2”
反而
“meg_code IN (1, 2)”
看看性能是否明显提高。我知道如果是 SQL,它不会有任何区别,但对于 INFORMIX,我不能 100% 确定。
SELECT t1.meg,t1.currency,t1.emp_num
FROM alt6sal t1
JOIN
(
Select yer.emp_num,yer.sal_year,MAX(mth.sal_mon) AS sal_mon
FROM
( SELECT emp_num, MAX(sal_year) AS sal_year
FROM alt6sal
WHERE meg_code IN ( 1, 2 )
GROUP BY emp_num
)yer
JOIN alt6sal mth
ON yer.sal_year = mth.sal_year AND yer.emp_num=mth.emp_num
AND mth.meg_code IN (1,2)
GROUP BY yer.sal_year,yer.emp_num
)t2
ON t1.sal_year=t2.sal_year AND t1.sal_mon=t2.sal_mon AND t1.emp_num=t2.emp_num
AND t1.meg_code IN (1,2)