Doris 4.1.1-rc01 在 UNION DISTINCT + ORDER BY + LIMIT/OFFSET 且宽投影场景下返回错误结果

[gimmickj]

Doris 4.1.1-rc01 在 UNION DISTINCT + ORDER BY + LIMIT/OFFSET 且宽投影场景下返回错误结果

问题概述

我们在 Doris 4.1.1-rc01 上发现了一个 wrong-result 问题。

这条 SQL 最初来自一个 Entity Framework Core Provider（EFCore.Doris）生成的查询，但问题可以通过 直接使用 Doris FE 的 MySQL 协议执行原始 SQL 稳定复现，因此这看起来不是 EF 的实体物化、跟踪或查询层逻辑错误，而是 Doris 自身的查询计划/执行问题。

最关键的现象是：

• 窄投影：结果正确
• 宽投影：结果错误
• 改写成 ROW_NUMBER() 分页形式：结果正确

并且从 EXPLAIN 看，宽投影场景下 branch-local pushed VTOP-N 的排序键发生了错误变化。

---

Doris 版本

doris-4.1.1-rc01(AVX2) RELEASE
Built on Tue, 19 May 2026 15:00:57 CST

---

原始 EF Core 查询形状

对应的 LINQ 查询大致如下：

context.Customers
    .Where(c => c.City == "Berlin")
    .Union(context.Customers.Where(c => c.City == "London"))
    .OrderBy(c => c.ContactName)
    .Skip(1)
    .Take(1);

---

重要说明

虽然这条查询最初来自 EF Core，但问题可以通过 直接执行原始 SQL 复现。

在我的环境里，需要先执行：

USE northwind;

否则仅仅依赖连接串中的 Database=northwind，Doris FE 仍可能返回：

Current database is not set.

---

复现 SQL

1. 错误场景：宽投影

USE northwind;

SELECT `u`.`CustomerID`, `u`.`Address`, `u`.`City`, `u`.`CompanyName`, `u`.`ContactName`,
       `u`.`ContactTitle`, `u`.`Country`, `u`.`Fax`, `u`.`Phone`, `u`.`PostalCode`, `u`.`Region`
FROM (
    SELECT `c`.`CustomerID`, `c`.`Address`, `c`.`City`, `c`.`CompanyName`, `c`.`ContactName`,
           `c`.`ContactTitle`, `c`.`Country`, `c`.`Fax`, `c`.`Phone`, `c`.`PostalCode`, `c`.`Region`
    FROM `Customers` AS `c`
    WHERE `c`.`City` = 'Berlin'
    UNION
    SELECT `c0`.`CustomerID`, `c0`.`Address`, `c0`.`City`, `c0`.`CompanyName`, `c0`.`ContactName`,
           `c0`.`ContactTitle`, `c0`.`Country`, `c0`.`Fax`, `c0`.`Phone`, `c0`.`PostalCode`, `c0`.`Region`
    FROM `Customers` AS `c0`
    WHERE `c0`.`City` = 'London'
) AS `u`
ORDER BY `u`.`ContactName`
LIMIT 1 OFFSET 1;

实际结果

ALFKI | Obere Str. 57 | Berlin | Alfreds Futterkiste | Maria Anders | Sales Representative | Germany | 030-0076545 | 030-0074321 | 12209 |

期望结果

CONSH | Berkeley Gardens 12 Brewery | London | Consolidated Holdings | Elizabeth Brown | Sales Representative | UK | (171) 555-9199 | (171) 555-2282 | WX1 6LT |

---

对照场景

2. 窄投影时结果正确

USE northwind;

SELECT `u`.`CustomerID`, `u`.`ContactName`
FROM (
    SELECT `c`.`CustomerID`, `c`.`ContactName`
    FROM `Customers` AS `c`
    WHERE `c`.`City` = 'Berlin'
    UNION
    SELECT `c0`.`CustomerID`, `c0`.`ContactName`
    FROM `Customers` AS `c0`
    WHERE `c0`.`City` = 'London'
) AS `u`
ORDER BY `u`.`ContactName`
LIMIT 1 OFFSET 1;

正确结果

CONSH | Elizabeth Brown

3. 改写成 ROW_NUMBER() 后结果正确

USE northwind;

SELECT `t`.`CustomerID`, `t`.`Address`, `t`.`City`, `t`.`CompanyName`, `t`.`ContactName`,
       `t`.`ContactTitle`, `t`.`Country`, `t`.`Fax`, `t`.`Phone`, `t`.`PostalCode`, `t`.`Region`
FROM (
    SELECT `u`.*, ROW_NUMBER() OVER (ORDER BY `u`.`ContactName`) AS `rn`
    FROM (
        SELECT `c`.`CustomerID`, `c`.`Address`, `c`.`City`, `c`.`CompanyName`, `c`.`ContactName`,
               `c`.`ContactTitle`, `c`.`Country`, `c`.`Fax`, `c`.`Phone`, `c`.`PostalCode`, `c`.`Region`
        FROM `Customers` AS `c`
        WHERE `c`.`City` = 'Berlin'
        UNION
        SELECT `c0`.`CustomerID`, `c0`.`Address`, `c0`.`City`, `c0`.`CompanyName`, `c0`.`ContactName`,
               `c0`.`ContactTitle`, `c0`.`Country`, `c0`.`Fax`, `c0`.`Phone`, `c0`.`PostalCode`, `c0`.`Region`
        FROM `Customers` AS `c0`
        WHERE `c0`.`City` = 'London'
    ) AS `u`
) AS `t`
WHERE `t`.`rn` > 1 AND `t`.`rn` <= 2;

正确结果

CONSH | Berkeley Gardens 12 Brewery | London | Consolidated Holdings | Elizabeth Brown | Sales Representative | UK | (171) 555-9199 | (171) 555-2282 | WX1 6LT |

---

EXPLAIN 的关键差异

窄投影场景

branch-local pushed VTOP-N 使用的排序键是：

order by: ContactName ASC

这和外层查询的：

ORDER BY u.ContactName

是一致的，因此结果正确。

宽投影场景

外层查询仍然是：

ORDER BY u.ContactName

但 branch-local pushed VTOP-N 却变成了：

order by: Address ASC

也就是说，局部 TopN 的排序键被错误地从 ContactName 变成了 Address。

这看起来就是最终 wrong-result 的直接原因：局部先按错误的列做了截断，后续即使外层再按 ContactName 排序，也已经拿不到正确候选行。

---

已尝试但无效的排查项

以下设置都 没有改变错误结果，也没有改变计划形状：

SET disable_nereids_rules='PUSH_DOWN_TOP_N_THROUGH_UNION';
SET disable_nereids_rules='COLUMN_PRUNING';
SET disable_nereids_rules='PUSH_PROJECT_THROUGH_UNION';
SET disable_nereids_rules='PUSH_PROJECT_INTO_UNION';
SET disable_nereids_rules='ELIMINATE_SORT';
SET disable_nereids_rules='PUSH_DOWN_TOP_N_THROUGH_UNION,COLUMN_PRUNING,PUSH_PROJECT_THROUGH_UNION,PUSH_PROJECT_INTO_UNION';
SET enable_nereids_planner=false;

这意味着问题看起来不能通过简单关闭这些 rewrite rule 来规避。

---

为什么认为这是 Doris 问题

1. 问题可通过 Doris FE 的 MySQL 协议直接执行原始 SQL 复现。
2. 窄投影正确，宽投影错误，说明这不是简单的 SQL 语义误解。
3. ROW_NUMBER() 改写后结果正确，说明数据本身没有问题。
4. EXPLAIN 已经显示宽投影场景下 branch-local VTOP-N 使用了错误排序键（Address 而非 ContactName）。
5. 关闭多个 Nereids 规则、甚至设置 enable_nereids_planner=false，都没有改变结果和计划。

---

疑似问题范围

这个问题很像 Doris 在以下组合场景中的 wrong-result bug：

• UNION DISTINCT
• 外层 ORDER BY
• LIMIT/OFFSET
• 宽投影

目前最强的证据是：

• 窄投影正常
• 宽投影异常
• 宽投影下 branch-local TopN 的排序键从 ContactName 错误变成了 Address

---

补充说明

我们目前在 EF Core Provider 侧通过把这类查询改写成 ROW_NUMBER() 分页形式进行规避，但还是希望帮助定位 Doris 本身的根因。

如果需要，我也可以补充：

• 窄投影与宽投影的完整 EXPLAIN
• 实际执行使用的 session 变量
• 更小的最小复现 SQL