Edit: https://gist.github.com/alecco/9976dab8fda8256ed403054ed0a65... I think using a range of rows is overkill, at least for row-stores. And also in the majority of cases random rows are preferred than a range. In the case where the table has a simple Primary Key the query is easier. Select all the valid PKs (rows) ordered by random and then limit. SQLite gives access to the rowid making this query even simpler and…
For every pf your examples the database will do a full table scan. If i am wrong feel free to correct me. But i tried multiple approaches more than the ones discussed and as soon as you start using random() the database will scan every record.
2. To truly random sample k out of a set of n rows it's needed to know the set first.
3. Walking the rowid B-Tree should be relatively fast (and necessary because of 2.)
It may be the case a sub-range is good enough (e.g. the table is quite disordered relatively to the properties looked after). But this is very unusual and you should warn the users of this data because later on they might change
Imagine your sub-range picks rows created over the weekend or some other particular time-frame. Or an import from some other legacy system. This will not be representative of the full set in many ways.
If the system needs to do a lot of sampling queries, perhaps it would be better to make overnight an auxiliary table. You can make many sample tables and compare which ones deviate less from the actual table. This table will be small and could even have materialized views pre-computed with the most expensive computations.