извращения на марше

Выделить таблицу в отдельную базу данных и кинуть в tmpfs?

Не. Нельзя гарантировать, что сервер однажды не завершит работу аварийно.

Выделить таблицу в отдельную базу данных, кинуть её на виртуальную ФС в образе, скопировать образ в tmpfs и сделать из этих двух образов RAID1? :)

Какой ад :) А точно raid будет читать из tmpfs, а не с двух устройств поочерёдно? :)

У mdadm есть параметр --write-mostly:

-W, --write-mostly

subsequent devices listed in a --build, --create, or --add command will be flagged as 'write-mostly'. This is valid for RAID1 only and means that the 'md' driver will avoid reading from these devices if at all possible. This can be useful if mirroring over a slow link.

Возможно, сработает, если пометить образ на диске как write-mostly. Но да, это ад, и наверняка есть более хорошее решение.

Если делать так, то ещё можно вместо ФС на образе заставить InnoDB использовать raw-образ без ФС:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

А вот такую шткуку рассматривал? - https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html

например копию таблицы там держать.

Если page cache подходит, и таблица хранится в отдельном файле, то можно попробовать:

https://hoytech.com/vmtouch/

Locking files into memory so the OS won't evict them

можно еще вот такую штуку попробовать.

http://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html

оно не так быстро как in-memory db, но ближе к нему, и не надо извращаться с memory storage engine

О, а это чудесная штука. Стать демоном и потом mlockall — забавное решение.

Тормоза могут быть изза того что большой индекс на диске Тут могут помочь именованные кеши http://sqlinfo.ru/articles/info/3.html

И есть еще такая штука - горячий и холодный кеш, они как раз управляют вытеснением таблиц из памяти

Гениально! Скопировал в комментарий о пользователе.

Только поклонник systemd может посоветовать запихнуть своп в рамдиск :-)

Где ты увидел своп в рамдиск и при чём здесь systemd?

А тебе-то что не так?

Своп в рамдиск - это уже много лет иносказательное выражение :-)

И каким местом оно сюда применимо?

И каким местом оно сюда применимо?

Я не он, но. Применимо как пример беспощадной в своей бессмысленности оптимизации, проистекающей от избытка умений и непонимания происходящего, очевидно же.

Перенести эту таблицу в отдельный экземпляр mysql, работающий в отдельной cgroup, у которой всегда достаточно памяти для оптимальной работы этой таблицы

Ну или не маяться дурью и перенести данные с критичным временем доступа в redis с периодической записью на диск

Перенести эту таблицу в отдельный экземпляр mysql
и перенести данные с критичным временем доступа в redis

Не катит. Часто нужны JOIN'ы с другими таблицами.

В таком случае у тебя все таблицы критичны к скорости доступа, а не только одна на гиг. Остается только посоветовать обмазаться индексами для минимизации обращений непосредственно к строкам, ну или поменять базу на более умную, которая сумеет должным образаом соптимизировать джойны в этом направлении

Нет. Обычно то, что использует join-ы оперирует только с относительно свежими записями или не критично к производительности. Проблема в «чистых» запросах, но использующих полное сканирование таблицы.

Удваиваю за копию таблицы в памяти. Обмазаться тригерами на запись/обновление и всё нормально будет.

Если нужны джойны, то пихаем свою таблицу в отдельный инстанс и приклеиваем его к основной базе через http://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html

Если оно тормозит нередко в рамках одной базы, то с чего ему в итоге быстрее работать в federated-варианте с разносом баз? :)

Ну оно тормозит у тебя из-за того что таблицу из памяти вытесняет? А если сделаешь отдельный инстанс с гарантированным объемом памяти только для этой таблицы, то она будет всегда в пейдж кэше иннодб. За скорость федерейтед не скажу, не пробовал.