Motor óptimo para los pequeños de búsqueda de tablas en MySQL

Question

Tengo la siguiente pregunta:Estoy diseño de aplicaciones web con varias decenas de pequeñas tablas de búsqueda:Estas tablas usualy contiene tres columnas (ID, Nombre, Descripción) y un par de filas (en su mayoría de menos de 50, max es de aproximadamente 450).

Estas tablas de búsqueda se espera que el cambio sólo en raras ocasiones (vienen estándar, que cambia de vez en varios años) y sólo será utilizada para:

• opciones de relleno en html, seleccione
• se unió a otros registros en los informes

Sólo habrá SELECT declaraciones en estas tablas el 99% de las veces, pero no va a ser un buen montón de ellos.

Me pregunto, que motor de base de datos sería más eficiente para el uso?

Aquí están mis consideraciones:

MEMORIA

• pro:muy rápido
• con:si se bloquea el servidor, todos los datos están perdidos y necesitan ser recreado
• con:no admite claves foráneas

comprimido MyISAM

• pro:rápido
• con:no admite claves foráneas

InnoDB

• pro:clave externa de apoyo

Lo que me gustaría preguntar es si habrá ventaja significativa en el uso de algo diferente InnoDB - en cuanto al rendimiento

Gracias, Zbynek

Answer 1

He contestado a una pregunta similar en Agosto de 2011 : Que DBMS es bueno para el super-lecturas rápidas y una estructura de datos sencilla?

Puesto que usted está preguntando acerca de MySQL y que el motor de almacenamiento.Para ser honesto, es difícil de decir porque son raras las ocasiones cuando MyISAM puede superar a InnoDB cuando se trata de Seleccionar.

Aquí están algunos de mis últimos posts en esta controversia

• Sep 20, 2011 : Lo mejor de MyISAM y InnoDB
• May 03, 2012 : Que es más rápido, InnoDB o MyISAM?
• Jul 05, 2012 : InnoDB, MyISAM vs con muchos de los índices
• Sep 26, 2012 : La elección de MyISAM más de InnoDB para estos requisitos del proyecto;y opciones a largo plazo

Usted podría preguntar ahora :¿Por qué he favor MyISAM más de InnoDB ?

Echa un vistazo a este diagrama (creado por Vadim Tkachenko, Percona CTO)

MyISAM en la memoria caché de los índices y su tabla tendría 2 índices (CLAVE PRINCIPAL en el id, y un índice de Nombre).Por otro lado, InnoDB tiene muchas partes móviles, para acomodar, especialmente si la InnoDB grupo de Búfer tiene que cargar y despedir a 16K páginas periódicamente.

Para ser justos, debe hacer un experimento.

• Ir a mi post ¿Cuáles son las principales diferencias entre InnoDB y MyISAM?.Lea cuidadosamente.
• Instalación de un servidor de usar MyISAM y todas sus tablas usando ROW_FORMAT=Fixed (Ver mi post ¿Cuál es el impacto en el rendimiento de usar CHAR vs VARCHAR en un tamaño fijo de campo?) y el uso de una gran key_buffer_size.
• El programa de instalación de otro servidor usando InnoDB y un gran innodb_buffer_pool_size.
• Agregar sus datos de servidor y de consulta como loco.

Esto le dará la mejor evaluación para el Motor de Almacenamiento de elección para el conjunto de datos.

DARLE UNA OPORTUNIDAD !!!

Answer 2

• "Comprimido MyISAM" -- ¿qué es eso?Tal Vez "Archivo"?
• La compresión no es necesario;las mesas son demasiado pequeñas, y rápidamente será totalmente en caché.
• FOREIGN KEYS -- ¿Por qué?Ha depurado el código, ¿no?No habrá colgando cosas para ver.
• MEMORY no es razonable, si escribir 'reload' código que se ejecuta cada vez que le llevará hasta el servidor y las actualizaciones a la tabla está dirigido tanto a los MEMORY la tabla a la persistencia de copia de seguridad.
• MyISAM ROW_FORMAT=FIXED -- eso es una vieja wive del cuento;uso DYNAMIC y VARCHARs.
• InnoDB "agrupado" PRIMARY KEY hace búsquedas un poco más rápido que MyISAM para su propósito.
• ¿ saber que las tablas de búsqueda están causando una notable desaceleración de la economía?Tengo serias dudas de que lo son.
• ¿ no uso de las tablas de búsqueda para "continuo" de los valores, tales como FLOATs y DATEs.

Yo voto por InnoDB sin FKs.