# 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.

```sql
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](https://coordinatordb.com/docs/reference/statements/explain), [max_threads](https://coordinatordb.com/docs/reference/settings/session-settings/max-threads) and [query measurements](https://coordinatordb.com/docs/guides/clickhouse/performance-and-monitoring/isolate-query-bottlenecks).