You say that you have the 1.6GB file in RAMdisk. Do you note any significant HD activity while you execute a RootsMagic operation? Possibly the Journal file is being written to HD. Under some conditions, the Journal file can be as large as the database file. Normally it is written to the same directory as the database file so I would expect it to be written to the RAMdisk drive and if there was insufficient space there would be an error message.
I assume that you have lots of RAM since you can afford the RAMdisk allocation so I doubt that RootsMagic would benefit from more RAM (unless there is significant HD activity).
Your question assumes an absence of a database index on the Record Number and that adding such an index would speed up the process. The RootsMagic database has many tables and they are all indexed on their Primary Key and several on key combinations specifically for search optimisation. The Record Number (known variously as PersonID, OwnerID, HusbandID, WifeID, ChildID...) is indexed. SQLite is described as "extremely fast and efficient" in SQLite vs MySQL vs PostgreSQL:...
However, the application may not rely exclusively on the SQLite search functions which exploit the indexes; maybe it is doing some things in its high level language (Delphi) that are independent of SQLite and are taking undue time. One of these is display - it is my impression that RootsMagic can bog down with a very large result set from a SQLite query. I have seen similar behaviour with some SQLite managers. There is, I believe, grounds for and room for improvement in the code design.
A user cannot add a SQLite table Index for what I assume you mean is a specific Fact Type such as the Reference Number (builtin) or Soundex Number (user custom). However, FactTypeID is the Primary Key for the FactTypeTable which defines each unique fact type and has indexes on the Name, Abbrev and GEDCOM Tag fields. The EventTable contains the values for each instance of a FactType and is indexed on the OwnerID (Record Number) and EventType (FactType); your Soundex-like value is stored in the Details field of this table for which there is no explicit index. The SQLite Query Optimiser might create a temporary index for this field, depending on the nature of the query.
There is a SQLite database function called ANALYZE that has not been exposed in RootsMagic. What it does is gather statistics about the data that is stored in tables for the Query Optimizer to use in query planning. Whether it would help is moot, given that there are many predefined indexes directed at optimising specific queries.
There is a SQLite database function called VACUUM that is exposed under Database Tools as "Compact" which might be of some help - moreso for the database file on the HD than is likely for it in RAMdisk.