@@ -1533,7 +1533,7 @@ fn test_collect_left_join_keeps_hash_partitioned_build_side_coalesce() -> Result
 }
 
 // ========================================================================
-// Limits with a `skip`
+// Sort pushdown through limits
 // ========================================================================
 
 /// Keep sorting above an unordered limit so its input can stop early and only
@@ -1556,10 +1556,32 @@ fn test_keep_sort_above_unordered_limit_with_skip() -> Result<()> {
     Ok(())
 }
 
-/// Refining an existing ordering can still push a TopK below the limit. It must
-/// retain `skip + fetch` rows so the offset does not reduce the result count.
+/// `OFFSET` without `LIMIT` is a `GlobalLimitExec` with a `skip` and no
+/// `fetch`. It selects rows by input position like any limit, so the sort
+/// stays above it.
 #[test]
-fn test_sort_pushed_below_ordered_limit_with_skip_keeps_skip_rows() -> Result<()> {
+fn test_keep_sort_above_limit_with_skip_only() -> Result<()> {
+    let source = Arc::new(MockMultiPartitionExec::new(4));
+    let coalesce = Arc::new(CoalescePartitionsExec::new(source));
+    let limit = Arc::new(GlobalLimitExec::new(coalesce, 5, None));
+    let sort: Arc<dyn ExecutionPlan> =
+        Arc::new(SortExec::new(sort_expr_on("a", 0, true, true), limit));
+
+    let optimized = optimize_and_sanity_check(sort)?;
+    assert_snapshot!(plan_string(&optimized), @r"
+    SortExec: expr=[a@0 DESC], preserve_partitioning=[false]
+      GlobalLimitExec: skip=5, fetch=None
+        CoalescePartitionsExec
+          MockMultiPartitionExec
+    ");
+    Ok(())
+}
+
+/// A limit whose input ordering comes from the source, not a sort, keeps the
+/// finer sort above it: a TopK on `[a, b]` below the limit would keep the
+/// smallest rows by `[a, b]` instead of the first input rows.
+#[test]
+fn test_keep_sort_above_ordered_limit_with_skip() -> Result<()> {
     let source = Arc::new(MockMultiPartitionExec::new(4));
     let mut ordering = sort_expr_on("a", 0, false, false);
     let ordered_input = Arc::new(MockReqExec::new(
@@ -1573,11 +1595,51 @@ fn test_sort_pushed_below_ordered_limit_with_skip_keeps_skip_rows() -> Result<()
 
     let optimized = optimize_and_sanity_check(sort)?;
     assert_snapshot!(plan_string(&optimized), @r"
-    GlobalLimitExec: skip=5, fetch=10
-      SortExec: TopK(fetch=15), expr=[a@0 ASC NULLS LAST, b@1 ASC NULLS LAST], preserve_partitioning=[false], sort_prefix=[a@0 ASC NULLS LAST]
+    SortExec: expr=[a@0 ASC NULLS LAST, b@1 ASC NULLS LAST], preserve_partitioning=[false]
+      GlobalLimitExec: skip=5, fetch=10
         MockReqExec
           SortPreservingMergeExec: [a@0 ASC NULLS LAST]
             MockMultiPartitionExec
     ");
     Ok(())
 }
+
+/// A limit directly above a `SortExec` is the exception: the finer requirement
+/// replaces that sort's key rather than adding a sort below the limit. The TopK
+/// retains `skip + fetch` rows so the offset does not shrink the result.
+#[test]
+fn test_sort_pushed_into_sort_below_limit_with_skip() -> Result<()> {
+    let source = Arc::new(MockMultiPartitionExec::new(1));
+    let mut ordering = sort_expr_on("b", 1, false, false);
+    let inner_sort = Arc::new(SortExec::new(ordering.clone(), source));
+    let limit = Arc::new(GlobalLimitExec::new(inner_sort, 5, Some(10)));
+    ordering.extend(sort_expr_on("a", 0, false, false));
+    let sort: Arc<dyn ExecutionPlan> = Arc::new(SortExec::new(ordering, limit));
+
+    let optimized = optimize_and_sanity_check(sort)?;
+    assert_snapshot!(plan_string(&optimized), @r"
+    GlobalLimitExec: skip=5, fetch=10
+      SortExec: TopK(fetch=15), expr=[b@1 ASC NULLS LAST, a@0 ASC NULLS LAST], preserve_partitioning=[false]
+        MockMultiPartitionExec
+    ");
+    Ok(())
+}
+
+/// `LocalLimitExec` keeps the first `fetch` rows of each partition, so a finer
+/// sort is not pushed below it either.
+#[test]
+fn test_keep_sort_above_ordered_local_limit() -> Result<()> {
+    let source = Arc::new(MockMultiPartitionExec::new(1));
+    let limit = Arc::new(LocalLimitExec::new(source, 10));
+    let mut ordering = sort_expr_on("a", 0, false, false);
+    ordering.extend(sort_expr_on("b", 1, false, false));
+    let sort: Arc<dyn ExecutionPlan> = Arc::new(SortExec::new(ordering, limit));
+
+    let optimized = optimize_and_sanity_check(sort)?;
+    assert_snapshot!(plan_string(&optimized), @r"
+    SortExec: expr=[a@0 ASC NULLS LAST, b@1 ASC NULLS LAST], preserve_partitioning=[false]
+      LocalLimitExec: fetch=10
+        MockMultiPartitionExec
+    ");
+    Ok(())
+}
@@ -536,6 +536,27 @@ fn pushdown_requirement_to_children(
             )
             .then(|| Ok(vec![Some(parent_required)]))
             .transpose()
+    } else if plan.is::<GlobalLimitExec>() || plan.is::<LocalLimitExec>() {
+        // A limit selects rows by input position, so a sort pushed below it
+        // would change which rows it skips and keeps. The exception is a limit
+        // directly above a `SortExec` whose ordering the requirement refines:
+        // the pushdown replaces that sort's key rather than adding a sort
+        // below the limit, and only changes the tie-break of an explicit sort,
+        // as pushing into a `SortExec` with a fetch already does. Otherwise
+        // keep the sort above the limit, so the input can stop after
+        // `skip + fetch` rows and only the retained rows are sorted.
+        let refines_sort_below = plan.children()[0].is::<SortExec>()
+            && plan.output_ordering().is_some_and(|ordering| {
+                plan.equivalence_properties().requirements_compatible(
+                    parent_required.first().clone(),
+                    ordering.clone().into(),
+                )
+            });
+        if refines_sort_below {
+            Ok(Some(vec![Some(parent_required)]))
+        } else {
+            Ok(None)
+        }
     } else if plan.fetch().is_some()
         && plan.supports_limit_pushdown()
         && plan
@@ -567,7 +588,8 @@ fn pushdown_requirement_to_children(
                 parent_required.clone()
             };
 
-        // Keep sorting above an unordered limit so the input can stop early.
+        // With no output ordering to refine, a sort below this fetch would
+        // change which rows it keeps, so keep the sort above it.
         let Some(ordering) = plan.properties().output_ordering() else {
             return Ok(None);
         };
 
@@ -361,6 +361,106 @@ SELECT * FROM (SELECT a FROM t1 LIMIT 4 OFFSET 3) ORDER BY a;
 6
 7
 
+# Which rows a limit keeps depends on its input order, so repeat the check on
+# unsorted data: `LIMIT 4 OFFSET 3` returns input rows 4 to 7 (1, 7, 2, 10),
+# not the 4th to 7th smallest values.
+statement ok
+CREATE TABLE unsorted (a INT) AS VALUES (5), (3), (9), (1), (7), (2), (10), (4), (8), (6);
+
+query I
+SELECT * FROM (SELECT a FROM unsorted LIMIT 4 OFFSET 3) ORDER BY a;
+----
+1
+2
+7
+10
+
+# `OFFSET` without `LIMIT` also selects rows by position, so the sort stays
+# above it: it skips the first 3 input rows (5, 3, 9), not the 3 smallest values.
+query TT
+EXPLAIN SELECT * FROM (SELECT a FROM unsorted OFFSET 3) ORDER BY a;
+----
+logical_plan
+01)Sort: unsorted.a ASC NULLS LAST
+02)--Limit: skip=3, fetch=None
+03)----TableScan: unsorted projection=[a]
+physical_plan
+01)SortExec: expr=[a@0 ASC NULLS LAST], preserve_partitioning=[false]
+02)--GlobalLimitExec: skip=3, fetch=None
+03)----DataSourceExec: partitions=1, partition_sizes=[1]
+
+query I
+SELECT * FROM (SELECT a FROM unsorted OFFSET 3) ORDER BY a;
+----
+1
+2
+4
+6
+7
+8
+10
+
+# The same holds when the input is ordered on a prefix of the requested
+# ordering: a `TopK` on `(a, b)` below the limit would keep the 7 smallest rows
+# by `(a, b)` instead of the first 7 input rows.
+query I
+COPY (SELECT column1 AS a, column2 AS b FROM (VALUES
+  (1, 9), (1, 8), (1, 7), (1, 6), (1, 5), (1, 4), (1, 3), (1, 2), (2, 1), (3, 0)))
+TO 'test_files/scratch/limit/ordered_prefix.parquet' STORED AS PARQUET;
+----
+10
+
+statement ok
+CREATE EXTERNAL TABLE ordered_prefix (a BIGINT, b BIGINT)
+STORED AS PARQUET
+WITH ORDER (a ASC)
+LOCATION 'test_files/scratch/limit/ordered_prefix.parquet';
+
+query TT
+EXPLAIN SELECT * FROM (SELECT a, b FROM ordered_prefix LIMIT 4 OFFSET 3) ORDER BY a, b;
+----
+logical_plan
+01)Sort: ordered_prefix.a ASC NULLS LAST, ordered_prefix.b ASC NULLS LAST
+02)--Limit: skip=3, fetch=4
+03)----TableScan: ordered_prefix projection=[a, b], fetch=7
+physical_plan
+01)SortExec: expr=[a@0 ASC NULLS LAST, b@1 ASC NULLS LAST], preserve_partitioning=[false]
+02)--GlobalLimitExec: skip=3, fetch=4
+03)----DataSourceExec: file_groups={1 group: [[WORKSPACE_ROOT/datafusion/sqllogictest/test_files/scratch/limit/ordered_prefix.parquet]]}, projection=[a, b], limit=7, output_ordering=[a@0 ASC NULLS LAST], file_type=parquet
+
+query II
+SELECT * FROM (SELECT a, b FROM ordered_prefix LIMIT 4 OFFSET 3) ORDER BY a, b;
+----
+1 3
+1 4
+1 5
+1 6
+
+# When the input ordering comes from an explicit sort, the finer sort is pushed
+# into that sort instead, as already happens when a limit without OFFSET is
+# fused into its sort. The TopK keeps `skip + fetch` (3 + 4 = 7) rows so the
+# limit still returns 4.
+query TT
+EXPLAIN SELECT * FROM (SELECT a, b FROM ordered_prefix ORDER BY b LIMIT 4 OFFSET 3) ORDER BY b, a;
+----
+logical_plan
+01)Sort: ordered_prefix.b ASC NULLS LAST, ordered_prefix.a ASC NULLS LAST
+02)--Limit: skip=3, fetch=4
+03)----Sort: ordered_prefix.b ASC NULLS LAST, fetch=7
+04)------TableScan: ordered_prefix projection=[a, b]
+physical_plan
+01)GlobalLimitExec: skip=3, fetch=4
+02)--SortExec: TopK(fetch=7), expr=[b@1 ASC NULLS LAST, a@0 ASC NULLS LAST], preserve_partitioning=[false]
+03)----DataSourceExec: file_groups={1 group: [[WORKSPACE_ROOT/datafusion/sqllogictest/test_files/scratch/limit/ordered_prefix.parquet]]}, projection=[a, b], file_type=parquet, predicate=DynamicFilter [ empty ], sort_order_for_reorder=[b@1 ASC NULLS LAST, a@0 ASC NULLS LAST], dynamic_rg_pruning=eligible
+
+query II
+SELECT * FROM (SELECT a, b FROM ordered_prefix ORDER BY b LIMIT 4 OFFSET 3) ORDER BY b, a;
+----
+1 3
+1 4
+1 5
+1 6
+
 # The aggregate does not need to be computed because the input statistics are exact and
 # an OFFSET, but no LIMIT, is specified.
 query TT