Мирон

и что, вы взяли коэффициент к в 0 часов, ав 0 часов 1'' коэффициент k поменялся k`, и кто-то тем старым коэффициентом k воспользовался.
Вы серьезно ок забыть, какой он был?
Наверное даже во время запроса по списку, часть коэффициентов изменится, по мере считывания, при том, что все, как задумано,но по-честному Вам бы наверное хотелось список "к" в 0 часов список в 0 часов + 1 версия + 2 ... n версия.
Учитывая 300 значений/3 секунды по 32 бита на каждый получаем 1,2МБ в час. В принципе копейки для MySQL
Редиску можно встроить для текущего слепка, если хочется немедленный ответ из буфера.

А Вы не пробовали добавить индекс на поле из 4-х байтов?
На MySQL индексы работают вполне приемлемо, главное, чтобы это был первый индекс созданный на таблице, тогда InnoDB ( default ) движок по умолчанию создаст кластеризованный индекс.
Вот синтаксис: https://dev.mysql.com/doc/refman/8.0/en/create-ind...
обратите внимание на варианты UNIQUE, это поможет подтвердить, что ключ каждого текстового поля действительно уникальный.
Потом, во время запроса, надо будет аккуратно проверить синтаксис, чтобы подтвердить что запрос создан так, что индекс будет использован - тип данных в WHERE должен соответствовать, и что запрос действительно его использует ( по моему в MySQL это опция EXPLAIN ).
Если все сделано верно, то скорость выполнения запроса с миллиардом записей должна быть вполне приемлема.
Осталось проверить некоторые детали. Из вопроса не очень понятно, если база многопользовательская, или обслуживает пользователя работающего на этой же машине, есть ли одновременный доступ нескольких пользователей, иными словами доп информация по масштабу использования базы может помочь. И хотя SQLite намекает на чисто локальный характер записей, это детали которые лучше подтвердить, чем оставить за кадром.
Кроме того, какой характер ключа из 4 байтов, это число или бинарная конструкция, если бинарная, приемлемо ли его перевести к типу Integer, это существенно для скорости индекса.
---
Если же индекс уже создан, и не показывает результаты, которые Вы ожидаете, детали запрошенные выше помогут разобраться.

В принципе справочник, это сущность. В СУБД каждая линейка, это сущность. То есть паритет по свойствам между объектами - сущностями и записями в СУБД будет
Сущность/объект - запись в СУБД.
В противном случае, представьте, у Вас таблица
"Справочник"
У Вас есть программа, в программе есть клиент СУБД и пользуясь этим клиентом Вы заносите в СУБД таблицу "Справочник" справочник с полями
№ - от 1 до макс 32 битовое число
Значение - допустим слово русского языка
----
Проходит 10 минут и разработчику так нравится то, что получилось, что он решает точно так же распорядиться другим справочником, теперь это имена городов с номером.
----
И как Вы теперь эти справочники сможете идентифицировать, которая запись принадлежит которому справочнику? Это уже сделать не получится.
Возможно пример немного притянут за уши, но мне кажется суть описана хорошо.

Если Вам нужен очень быстрый ответ, разбиваете имена городов на буквы, создаёте XML индекс, и выбираете имена городов во временную таблицу после чего заканчиваете запрос по ключу города. В Постгрес столько расширений что я почти уверен, вы найдете все ответы за несколько запросов в Яндексе.