[Bug] Limit Insert ORDER BY ... LIMIT 5000000 hangs after 17c161a3

[Ariznawlll]

结论

在 3-CN TKE big-data 环境中，Limit Insert 场景出现稳定超时；二分定位首个异常 commit 为 17c161a（fix(mergetop): handle large LIMIT safely (#27999)）。

复现步骤

1. 使用 3-CN MatrixOne 集群，准备 100M 行基础表。
2. 执行：
   insert into big_data_test.insert_into_table_limit select * from big_data_test.table_basic_for_load_100M order by col4 limit 5000000;
3. 观察执行时间和客户端返回结果。

对比结果

• Good commit 0db2d5ea9a39d281914275fa83108029fe30bfba：PASS，约 306 秒。
• First bad 17c161a31b47a22e71ca222839143f66717ac365：900 秒超时（15 分钟），未完成。
• 后续 20b43edbf2ddd1667ca0492c806a950b748d9e6b：同样 900 秒超时。

影响

大数据场景下带 ORDER BY + LIMIT 的 INSERT ... SELECT 可能长时间无法完成，超过回归测试允许时限。

相关验证

• Regression run: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/34037170001
• Good run: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/34033674100
• Commit: 17c161a

[XuPeng-SH]

Implemented in #28288 with a version-gated hierarchical ordered-stream Top-N merge. Matched 55 validation: 10M/K=500K improves from 21.19-21.49s on main to 3.56-3.62s; the issue-shaped 100M/K=5M completes in 111.57s with exactly 5,000,000 distinct keys while the same main build remains incomplete at 300s. The 1M/K=500K control stays on the existing fast path (1.286s), because forcing the hierarchy there regressed to 2.82-2.94s. Cancellation rolls INSERT back to zero and a following query succeeds. The PR body contains the complete QA test plan, protocol fallback, counterexamples, SCA, race, and baseline-failure evidence.

[Ariznawlll]

测试版本

• 分支：codex/limit-insert-timeout-15-v2（昨天二分使用的分支）
• commit：4fdb9e91615f9fc37703039ae28a47849206d1d6（MatrixOne PR fix(top): bound distributed large Top-N merge #28288 合并提交）
• 部署方式：3-CN TKE big-data 环境
• 测试日期：2026-09-07

原问题验证

准备 100M 行基础表后执行原始复现 SQL：

insert into big_data_test.insert_into_table_limit
select * from big_data_test.table_basic_for_load_100M
order by col4 limit 5000000;

执行完成并返回成功，耗时约 253.4 秒；随后执行 select count(*) from big_data_test.insert_into_table_limit 校验正常，未发生 15 分钟超时。

Happy Path 覆盖

1. 原始 ORDER BY ... LIMIT 5000000 INSERT...SELECT：通过，返回成功。
2. 结果行数校验：通过，目标表查询成功。

Unhappy Path 覆盖

本次 issue 验证未执行额外的取消、异常注入或非法输入路径；这些路径不属于本次修复的原始复现条件。

白盒验证

不适用。本次验证使用公开 SQL 复现原始问题。

回归测试

已在 mo-nightly big-data Limit Insert focused 流程中验证：回归分支为 codex/limit-insert-timeout-15-v2，测试范围为 limit_insert。

测试证据

Big Data Test run #34090751287

关键日志：固定镜像 commit-4fdb9e9，Limit Insert 结果为 PASS，耗时 255 秒，整个 workflow 成功。

测试结论

测试通过。