BTREE is great for fetching a range of values (id BETWEEN 1111 AND 2222).
HASH is terrible for ranges.
Both are good for fetching a single value; HASH is better.
Are the 5000 rows all the same INT? (What does the SELECT look like?)
A MEMORY table would be about 300MB, so it sounds feasible.
If the data does not change, do this when you start up:
CREATE TABLE mem (
int_val INT NOT NULL,
flt_val FLOAT NOT NULL,
INDEX(int_val) BTREE? HASH?
) MEMORY;
INSERT INTO mem
SELECT int_val, flt_val FROM persistent_tbl;
You probably don't need the BIGINT to be indexed; the INT is probably not UNIQUE? You probably don't need the id?
This way, no stored proc is needed for constructing the table.
What will you do with the 5000 rows? Process them in some language? Do SUM, AVG, GROUP BY? If so, fine.
Thinking out of the box... If not, and you are only selecting by a single INT, and that returns 5000 rows, perhaps the structure is not optimal. Consider preprocessing the data into a diff table; it would have one row per distinct INT. The rest of the data (just the float?) would be serialized (I like JSON) as a big BLOB. This preprocessed stuff would be about 15M/5000 = 3000 rows. And you would be fetching one row -- that should be 20x faster than fetching 5000 rows.