Mirando la lista de disponibilidad de funciones en http://dev.mysql.com/doc/refman/5.1/en/memory-storage-engine.html, dos posibles problemas saltan a la luz:
- No se necesitan transacciones ni soporte FK, lo que significa que tendrá que administrar la integridad transaccional y la integridad referencial en su propio código (lo que podría terminar siendo mucho menos eficiente que dejar que la base de datos haga esto por usted, aunque eso depende mucho de la aplicación) patrones de comportamiento esperados).
- Solo bloqueo de nivel de tabla: esto podría ser una barrera importante para la escalabilidad si su aplicación necesita múltiples escritores concurrentes en el mismo conjunto de tablas o en los casos en que sus operaciones de lectura usan bloqueos para garantizar que se lean datos consistentes, en tales casos una tabla basada en disco que admite una granularidad de bloqueo mucho más fina funcionará mucho mejor si una cantidad suficiente de su contenido se almacena actualmente en la memoria caché
Aparte de eso, suponiendo que tenga suficiente RAM, una tabla basada en memoria debería ser más rápida que una basada en disco. Obviamente, debe tener en cuenta tomar instantáneas en el disco para abordar el problema de lo que sucede cuando se restablece la instancia del servidor, lo que probablemente negará por completo el beneficio de rendimiento en general si los datos necesitan capturarse con frecuencia (si puede vivir con la pérdida de un día de datos en tal caso, podría hacer una copia de seguridad una vez al día, pero en la mayoría de los casos eso no sería aceptable).
Una alternativa podría ser:
- Use tablas basadas en disco, pero asegúrese de tener RAM más que suficiente para mantenerlas todas en RAM en cualquier momento dado (y "suficiente RAM" podría ser más de lo que piensa, ya que necesita dar cuenta de cualquier otro proceso en la máquina, SO IO buffers / cache y así sucesivamente)
- Escanee todo el contenido (todas las páginas de datos e índices) de la tabla en cada inicio para precargar el contenido en la memoria
SELECT * FROM <table> ORDER BY <pkey fields>para cada tabla seguido de SELECT <indexed fields> FROM <table> ORDER BY <index fields>para cada índice
De esta manera, todos sus datos están en RAM, solo tiene que preocuparse por el rendimiento de E / S para las operaciones de escritura. Si el conjunto de trabajo común de su aplicación es mucho más pequeño que toda la base de datos (que suele ser el caso, en la mayoría de las aplicaciones, la mayoría de los usuarios solo mirarán los datos más recientes, si es el momento), podría ser mejor ser más selectivo sobre cuánto escanea para precargar en memoria, permitiendo que el resto se cargue desde el disco a pedido.