E sobre essa ideia:
... como uma espécie de substituto do pobre para revisitar todas as rotinas de código usando o banco de dados e implementando o memcached ou similar.
Use o mecanismo de armazenamento MEMORY em um slave somente leitura para fazer suas leituras, é exatamente o que você realmente quer e uma configuração sã. Esqueça "despejá-lo no disco" (?!) Ou outras coisas estranhas.
Você pode até mesmo colocar o escravo como outra instância em seu servidor existente se não puder configurar um escravo dedicado, mas o ajuste adequado dos parâmetros do MySQL para cargas de trabalho de leitura maior trará um aprimoramento de desempenho significativo também!
use o mecanismo innodb para todas as suas tabelas, em my.cnf configure innodb_buffer_pool_size para 2-3GB de RAM, durante a inicialização, execute a varredura completa da tabela para todas as tabelas [ou apenas mysqldump -A]. isso deve dar a você um desempenho de leitura muito decente se você tiver bons índices em todas as tabelas.
também, se você usar esta solução, seu código será mais simples - você não precisará fazer a sincronização de volta das tabelas in-MEMORY para as tabelas myisam / on-disk.
Filmado no escuro, mas você está enfrentando problemas de desempenho primeiro?
Em segundo lugar, se você está tendo problemas de desempenho, terá que ver o ajuste. Sintonize o aplicativo (se você for o dev ou tiver privilégios de estrangulamento nos desenvolvedores) para usar as consultas adequadas para que você não esteja usando JOINs enormes e tal.
Em seguida, observe a arquitetura do banco de dados. Fazendo soluções alternativas patetas vai tornar uma dor de cabeça maior para gerenciar mais tarde. As etapas que você segue dependem do seu caso de uso. Você pode considerar fazer com que um servidor robusto seja dimensionado verticalmente, depois colocá-lo atrás de um servidor de memcached e criar um escravo somente leitura para coisas como a execução de relatórios e backups.
Não tire a RAM do banco de dados para tentar um esquema que subtraia as boas práticas. Há blogs para ajuste de banco de dados de alto desempenho disponíveis para dar ideias e o blog de podcast StackOverflow tem estatísticas sobre como esse site é executado (MS Stack); tráfego relativamente pesado, mas não uma configuração complicada.