Native SQL Pagination Limits with setMaxResults

Investigate how setMaxResults interacts with Hibernate query execution when native SQL is employed, given that the first-level cache does not support pagination parameters. The documented behavior specifies that setFirstResult defines a zero-based index and setMaxResults limits result count, but exact SQL generation varies by dialect. A precise goal is to determine whether omitting an explicit orderBy clause with setFirstResult produces non-deterministic ordering when entities are cached across Hibernate 5.x and 6.x. Constraints include the requirement for ordered result sets to ensure deterministic pagination and the performance impact of large offset values due to database row scanning. Uncertainty remains about how dialect-specific LIMIT/OFFSET syntax affects result boundaries when the cache bypasses first/max results entirely.

Does the absence of cache support for setFirstResult/setMaxResults introduce ordering inconsistencies when native SQL pagination is combined with a default entity identifier order? Can dialect-dependent LIMIT/OFFSET generation cause silent result set truncation at high offset values? Is there a documented strategy to enforce deterministic pagination without explicit orderBy when using native SQL queries?