There is no such thing as a "row index" in a relational database (note that a relation database contains rows, not "records"), but if you can find a column by which to sort the result this can easily be done using a window function:
select c1,
row_number() over (order by some_column) as record_index
from the_table
order by record_index;
(You didn't specify your DBMS, the above is ANSI SQL)
Edit
if you don't have a column to sort on, you can try sorting by a constant value instead which will bring back the rows "unordered":
select record_index,
row_number() over (order by 42) as record_index
from the_table
order by record_index;
But again: there is no such thing as a "natural" order of rows. There might be one on disk, but that is most likely not the one that is being used during retrieval - especially when the table doesn't have a clustered index (Oracle does not use a clustered index by default, Postgres doesn't have them at all).
A DBMS might also apply additional optimizations when retrieving the data. Oracle, Postgres and I believe SQL Server as well can e.g. "hop" on a table scan from a different session to optimize the phyiscal read from disk. In that case two concurrent selects will show a different "order" even though the phyiscal layout on the harddisk didn't change.
And then you have changes to the physical storage due to updates (e.g. if a row doesn't fit on the block any longer because its size increased).