Choose an explicit result order ​

Only ORDER BY promises a result order. A result that happens to arrive in key order can change after the data, predicate or access plan changes. Add a unique tie breaker when the application paginates or compares repeated results.

SELECT id, amount
FROM orders
WHERE id >= 1000
ORDER BY id
LIMIT 100;

Separate ordering from concurrency ​

Coordinator DB does not expose asynchronous read scheduling or a read-in-order switch. Use the documented SQL order and examine EXPLAIN QUERY PLAN rather than porting settings from another database. Increasing max_threads also does not establish an order or guarantee that a particular statement runs in parallel.

If the final sort is expensive, filter earlier and return only the columns the reader needs. Test a representative key range, then compare duration and peak memory in system.query_log. Keep ORDER BY in every export that requires reproducible row order; applying a limit without an order selects an unspecified subset.

For repeated pages, a predicate such as id > last_seen_id with ORDER BY id can make the page boundary explicit. The application must decide how concurrent inserts affect the overall export.

See EXPLAIN, max_threads and query measurements.