Question

Is a table intrinsically sorted by it’s primary key? If I have a table with the primary key on a BigInt identity column can I trust that queries will always return the data sorted by the key or do I explicitly need to add the “ORDER BY”. The performance difference is significant.

Answer 1

Data is physically stored by clustered index, which is usually the primary key but doesn’t have to be.

Data in SQL is not guaranteed to have order without an ORDER BY clause. You should always specify an ORDER BY clause when you need the data to be in a particular order. If the table is already sorted that way, the optimizer won’t do any extra work, so there’s no harm in having it there.

Without an ORDER BY clause, the RDBMS might return cached pages matching your query while it waits for records to be read in from disk. In that case, even if there is an index on the table, data might not come in in the index’s order. (Note this is just an example – I don’t know or even think that a real-world RDBMS will do this, but it’s acceptable behaviour for an SQL implementation.)

EDIT

If you have a performance impact when sorting versus when not sorting, you’re probably sorting on a column (or set of columns) that doesn’t have an index (clustered or otherwise). Given that it’s a time series, you might be sorting based on time, but the clustered index is on the primary bigint. SQL Server doesn’t know that both increase the same way, so it has to resort everything.

If the time column and the primary key column are a related by order (one increases if and only if the other increases or stays the same), sort by the primary key instead. If they aren’t related this way, move the clustered index from the primary key to whatever column(s) you’re sorting by.