Есть табличка общим "сухим" весом под 30 Гб (если сложить все колонки всех строк, не считая индексов).
Схема таблички примитивна, вида:


primary key - первый INT, скажем.
Есть два-три B+-Tree индекса по каким-то из INT/BIGINT колонкам.
Никаких foreign key и вообще чего-то умнее тут сказанного. Одна таблица. Транзакций длиннее одного INSERT нет. Рассматриваем табличку буквально как key=value хранилку.

Нагрузка:
1. 100 insert/delete в секунду.
2. 8000 select в секунду.

SELECT-ы в тестах были примитивны и двух видов



INSERT/UPDATE примерно похожи. Удалить что-то с данным id. Проапдейтить одну колонку у данного id.

Сейчас данные хранятся совсем не в MySQL, а в какой-то космической фундервафле, реализованной давно на каком-то голом C++/Go/Rust и живёт inmemory, практически не потребляет проца и отвечает за пол микросекунды и потянет ещё примерно 1000-кратный рост нагрузки.

Хотим эксперимент чтобы незнаю что. Поржать (над собой), поисследовать, посмотреть на мир шире, "нам сильно интересно и нечего делать", ваш вариант

Заливаем эту "табличку" в реальную табличку MySQL (mariadb) с вышеописанной схемой и, например, в PostgreSQL. Делаем транслятор запросов, который на лету пишет SELECT из меряет время ответа.

Если тестировать одни select, когда данные только что залиты и индексы никак не побиты рандомными изменениями и нет никаиких U-, D-операций, то оно медленнее текущего решения, но до одной миллисекунды чаще всего таки укладываются. Иногда что-то стреляет куда-то в небеса, но можно пренебречь, верю что можно положить всё в память, поиграться с параметрами, почитать пару десятков чужих диссертаций по настройке MySQL и сделать лучше.

В связи с этим вопросы примерно такие:

1. Что на таком "селектном" сценарии из параметров полезно будет поизучать/покрутить?
2. Да, читал, что для чтений оптимален движок MyISAM. Стоит его пробовать или я читал что-то совсем древнее и современные InnoDB-версии сами умные и там сглажена эта разница?
3. Мы не пробовали PostgreSQL, но может ли кто-то наванговать что мы там увидим по latency нашего селекта в описанном сценарии? Знаю там все боятся разряженности из-за реализации MVCC, при которой новые туплы всегда добавляются в блок/страницу, а старые потом когда-нибудь вакууммируются, в результате если хватает апдейтов, то движок много перешагивает ненужных данных, а не занимается полезной работой, но когда апдейтов мало, может и пронесёт - такие слухи.

Просьба откомментировать техническую сторону вопроса (без обсуждения безумия самих задач).
Спасибо.

Абсолютно неэффективно, ведь список постоянно разный.