type transacciones soporta referencial que por motor llama integridad establece engine ejemplos defecto almacenamiento mysql database performance innodb myisam

mysql - transacciones - que es motor de almacenamiento en phpmyadmin



MyISAM contra InnoDB (27)

Estoy trabajando en un proyecto que involucra muchas escrituras de base de datos, diría ( 70% inserciones y 30% lecturas ). Esta proporción también incluiría actualizaciones que considero una lectura y una escritura. Las lecturas pueden estar sucias (por ejemplo, no necesito información 100% precisa en el momento de la lectura).
La tarea en cuestión será hacer más de 1 millón de transacciones de base de datos por hora.

He leído un montón de cosas en la web sobre las diferencias entre MyISAM e InnoDB, y MyISAM me parece la opción obvia para la base de datos / tablas en particular que usaré para esta tarea. Por lo que parece que estoy leyendo, InnoDB es bueno si se necesitan transacciones ya que se admite el bloqueo a nivel de fila.

¿Alguien tiene alguna experiencia con este tipo de carga (o superior)? ¿Es MyISAM el camino a seguir?

He discussed brevemente esta pregunta en una tabla para que pueda concluir si desea utilizar InnoDB o MyISAM .

Aquí hay una pequeña descripción de qué motor de almacenamiento de datos debe usar en qué situación:

MyISAM InnoDB ---------------------------------------------------------------- Required full-text search Yes 5.6.4 ---------------------------------------------------------------- Require transactions Yes ---------------------------------------------------------------- Frequent select queries Yes ---------------------------------------------------------------- Frequent insert, update, delete Yes ---------------------------------------------------------------- Row locking (multi processing on single table) Yes ---------------------------------------------------------------- Relational base design Yes

Para resumir:

Frequent reading, almost no writing => MyISAM Full-text search in MySQL <= 5.5 => MyISAM

En todas las demás circunstancias, InnoDB suele ser el mejor camino a seguir.

He trabajado en un sistema de alto volumen utilizando MySQL y he probado tanto MyISAM como InnoDB.

Encontré que el bloqueo a nivel de tabla en MyISAM causó serios problemas de rendimiento para nuestra carga de trabajo que suena similar a la suya. Desafortunadamente, también encontré que el rendimiento bajo InnoDB también fue peor de lo que esperaba.

Al final, resolví el problema de la contención mediante la fragmentación de los datos, de modo que las inserciones se introdujeron en una tabla "activa" y las selecciones nunca se consultaron.

Esto también permitió que las eliminaciones (los datos fueran sensibles al tiempo y solo retuviéramos el valor de X días) se produjeran en tablas "obsoletas" que, de nuevo, no fueron tocadas por consultas de selección. InnoDB parece tener un rendimiento deficiente en las eliminaciones masivas, por lo que si planea purgar los datos, es posible que desee estructurarlos de tal manera que los datos antiguos se encuentren en una tabla obsoleta que simplemente se pueda eliminar en lugar de ejecutar eliminaciones en ella.

Por supuesto, no tengo idea de cuál es su aplicación, pero espero que esto le brinde una idea de algunos de los problemas con MyISAM e InnoDB.

InnoDB ofrece:

ACID transactions row-level locking foreign key constraints automatic crash recovery table compression (read/write) spatial data types (no spatial indexes)

En InnoDB, todos los datos en una fila excepto TEXT y BLOB pueden ocupar un máximo de 8,000 bytes. No hay indexación de texto completo disponible para InnoDB. En InnoDB, los COUNT (*) s (cuando no se usa WHERE, GROUP BY o JOIN) se ejecutan más lentamente que en MyISAM porque el recuento de filas no se almacena internamente. InnoDB almacena tanto los datos como los índices en un archivo. InnoDB utiliza un grupo de búferes para almacenar en caché los datos y los índices.

MyISAM ofrece:

fast COUNT(*)s (when WHERE, GROUP BY, or JOIN is not used) full text indexing smaller disk footprint very high table compression (read only) spatial data types and indexes (R-tree)

MyISAM tiene un bloqueo de nivel de tabla, pero ningún bloqueo de nivel de fila. No hay transacciones. No hay recuperación automática de fallos, pero ofrece funcionalidad de tabla de reparación. No hay restricciones de clave externa. Las tablas MyISAM generalmente tienen un tamaño más compacto en el disco en comparación con las tablas InnoDB. Las tablas MyISAM podrían reducirse aún más en tamaño al comprimirlas con myisampack si fuera necesario, pero convertirse en de solo lectura. MyISAM almacena los índices en un archivo y los datos en otro. MyISAM usa buffers clave para almacenar índices en caché y deja la administración del almacenamiento en caché de datos al sistema operativo.

En general, recomendaría InnoDB para la mayoría de los propósitos y MyISAM solo para usos especializados. InnoDB es ahora el motor predeterminado en las nuevas versiones de MySQL.

La gente a menudo habla de rendimiento, lecturas en comparación con escrituras, claves externas, etc., pero en mi opinión hay otra característica imprescindible para un motor de almacenamiento: actualizaciones atómicas.

Prueba esto:

  1. Emita una ACTUALIZACIÓN en su tabla MyISAM que demore 5 segundos.
  2. Mientras la ACTUALIZACIÓN está en progreso, diga 2.5 segundos, presione Ctrl-C para interrumpirla.
  3. Observa los efectos sobre la mesa. ¿Cuántas filas se actualizaron? ¿Cuántos no fueron actualizados? ¿Es la tabla incluso legible, o se corrompió cuando presionó Ctrl-C?
  4. Intente el mismo experimento con ACTUALIZAR contra una tabla InnoDB, interrumpiendo la consulta en curso.
  5. Observe la tabla InnoDB. Se actualizaron cero filas. InnoDB le ha asegurado que tiene actualizaciones atómicas, y si la actualización completa no se pudo confirmar, revierte todo el cambio. Además, la tabla no está corrupta. Esto funciona incluso si utiliza killall -9 mysqld para simular un bloqueo.

El rendimiento es deseable, por supuesto, pero no perder datos debería superar eso.

No soy un experto en bases de datos, y no hablo por experiencia. Sin embargo:

Las tablas MyISAM utilizan el bloqueo a nivel de tabla . Según sus estimaciones de tráfico, tiene cerca de 200 escrituras por segundo. Con MyISAM, solo uno de estos podría estar en progreso en cualquier momento . Debe asegurarse de que su hardware pueda mantenerse al día con estas transacciones para evitar ser invadido, es decir, una sola consulta no puede tomar más de 5 ms.

Eso me sugiere que necesitaría un motor de almacenamiento que admita el bloqueo a nivel de fila, es decir, InnoDB.

Por otro lado, debería ser bastante trivial escribir algunos scripts simples para simular la carga con cada motor de almacenamiento y luego comparar los resultados.

Para agregar a la amplia selección de respuestas que cubren las diferencias mecánicas entre los dos motores, presento un estudio empírico de comparación de velocidad.

En términos de velocidad pura, no siempre es el caso de que MyISAM sea más rápido que InnoDB, pero en mi experiencia, tiende a ser más rápido para los entornos de trabajo PURE READ en un factor de aproximadamente 2.0-2.5 veces. Claramente, esto no es apropiado para todos los entornos, como han escrito otros, MyISAM carece de elementos como transacciones y claves externas.

He hecho un poco de evaluación comparativa a continuación: he utilizado python para bucles y la biblioteca timeit para las comparaciones de tiempos. Para el interés, también he incluido el motor de memoria, esto brinda el mejor rendimiento en todos los ámbitos, aunque solo es adecuado para tablas más pequeñas (siempre se encuentra The table ''tbl'' is full cuando excede el límite de memoria de MySQL). Los cuatro tipos de selección que miro son:

  1. selecciones de vainilla
  2. cuenta
  3. selecciones condicionales
  4. Sub-selecciones indexadas y no indexadas

En primer lugar, creé tres tablas usando el siguiente SQL

CREATE TABLE data_interrogation.test_table_myisam ( index_col BIGINT NOT NULL AUTO_INCREMENT, value1 DOUBLE, value2 DOUBLE, value3 DOUBLE, value4 DOUBLE, PRIMARY KEY (index_col) ) ENGINE=MyISAM DEFAULT CHARSET=utf8

con ''MyISAM'' sustituido por ''InnoDB'' y ''memory'' en la segunda y tercera tablas.

1) Vanilla selecciona

Consulta: SELECT * FROM tbl WHERE index_col = xx

Resultado: empate

La velocidad de estos es en general la misma, y ​​como se espera es lineal en el número de columnas que se seleccionarán. InnoDB parece un poco más rápido que MyISAM, pero esto es realmente marginal.

Código:

import timeit import MySQLdb import MySQLdb.cursors import random from random import randint db = MySQLdb.connect(host="...", user="...", passwd="...", db="...", cursorclass=MySQLdb.cursors.DictCursor) cur = db.cursor() lengthOfTable = 100000 # Fill up the tables with random data for x in xrange(lengthOfTable): rand1 = random.random() rand2 = random.random() rand3 = random.random() rand4 = random.random() insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" cur.execute(insertString) cur.execute(insertString2) cur.execute(insertString3) db.commit() # Define a function to pull a certain number of records from these tables def selectRandomRecords(testTable,numberOfRecords): for x in xrange(numberOfRecords): rand1 = randint(0,lengthOfTable) selectString = "SELECT * FROM " + testTable + " WHERE index_col = " + str(rand1) cur.execute(selectString) setupString = "from __main__ import selectRandomRecords" # Test time taken using timeit myisam_times = [] innodb_times = [] memory_times = [] for theLength in [3,10,30,100,300,1000,3000,10000]: innodb_times.append( timeit.timeit(''selectRandomRecords("test_table_innodb",'' + str(theLength) + '')'', number=100, setup=setupString) ) myisam_times.append( timeit.timeit(''selectRandomRecords("test_table_myisam",'' + str(theLength) + '')'', number=100, setup=setupString) ) memory_times.append( timeit.timeit(''selectRandomRecords("test_table_memory",'' + str(theLength) + '')'', number=100, setup=setupString) )

2) cuentas

Consulta: SELECT count(*) FROM tbl

Resultado: MyISAM gana

Este demuestra una gran diferencia entre MyISAM e InnoDB: MyISAM (y la memoria) realiza un seguimiento del número de registros en la tabla, por lo que esta transacción es rápida y O (1). La cantidad de tiempo requerido para que InnoDB cuente aumenta de forma superlineal con el tamaño de la tabla en el rango que investigué. Sospecho que muchas de las aceleraciones de las consultas de MyISAM que se observan en la práctica se deben a efectos similares.

Código:

myisam_times = [] innodb_times = [] memory_times = [] # Define a function to count the records def countRecords(testTable): selectString = "SELECT count(*) FROM " + testTable cur.execute(selectString) setupString = "from __main__ import countRecords" # Truncate the tables and re-fill with a set amount of data for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]: truncateString = "TRUNCATE test_table_innodb" truncateString2 = "TRUNCATE test_table_myisam" truncateString3 = "TRUNCATE test_table_memory" cur.execute(truncateString) cur.execute(truncateString2) cur.execute(truncateString3) for x in xrange(theLength): rand1 = random.random() rand2 = random.random() rand3 = random.random() rand4 = random.random() insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" cur.execute(insertString) cur.execute(insertString2) cur.execute(insertString3) db.commit() # Count and time the query innodb_times.append( timeit.timeit(''countRecords("test_table_innodb")'', number=100, setup=setupString) ) myisam_times.append( timeit.timeit(''countRecords("test_table_myisam")'', number=100, setup=setupString) ) memory_times.append( timeit.timeit(''countRecords("test_table_memory")'', number=100, setup=setupString) )

3) Selecciones condicionales

Consulta: SELECT * FROM tbl WHERE value1<0.5 AND value2<0.5 AND value3<0.5 AND value4<0.5

Resultado: MyISAM gana

Aquí, MyISAM y la memoria realizan aproximadamente lo mismo, y superan a InnoDB en aproximadamente un 50% para tablas más grandes. Este es el tipo de consulta para la cual los beneficios de MyISAM parecen estar maximizados.

Código:

myisam_times = [] innodb_times = [] memory_times = [] # Define a function to perform conditional selects def conditionalSelect(testTable): selectString = "SELECT * FROM " + testTable + " WHERE value1 < 0.5 AND value2 < 0.5 AND value3 < 0.5 AND value4 < 0.5" cur.execute(selectString) setupString = "from __main__ import conditionalSelect" # Truncate the tables and re-fill with a set amount of data for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]: truncateString = "TRUNCATE test_table_innodb" truncateString2 = "TRUNCATE test_table_myisam" truncateString3 = "TRUNCATE test_table_memory" cur.execute(truncateString) cur.execute(truncateString2) cur.execute(truncateString3) for x in xrange(theLength): rand1 = random.random() rand2 = random.random() rand3 = random.random() rand4 = random.random() insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" cur.execute(insertString) cur.execute(insertString2) cur.execute(insertString3) db.commit() # Count and time the query innodb_times.append( timeit.timeit(''conditionalSelect("test_table_innodb")'', number=100, setup=setupString) ) myisam_times.append( timeit.timeit(''conditionalSelect("test_table_myisam")'', number=100, setup=setupString) ) memory_times.append( timeit.timeit(''conditionalSelect("test_table_memory")'', number=100, setup=setupString) )

4) Sub-selecciones

Resultado: InnoDB gana

Para esta consulta, creé un conjunto adicional de tablas para la sub-selección. Cada una es simplemente dos columnas de BIGINT, una con un índice de clave principal y otra sin ningún índice. Debido al gran tamaño de la mesa, no probé el motor de memoria. El comando de creación de la tabla SQL era

CREATE TABLE subselect_myisam ( index_col bigint NOT NULL, non_index_col bigint, PRIMARY KEY (index_col) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

donde una vez más, ''MyISAM'' se sustituye por ''InnoDB'' en la segunda tabla.

En esta consulta, dejo el tamaño de la tabla de selección en 1000000 y, en cambio, varío el tamaño de las columnas sub-seleccionadas.

Aquí el InnoDB gana fácilmente. Después de llegar a una tabla de tamaño razonable, ambos motores escalan linealmente con el tamaño de la subselección. El índice acelera el comando MyISAM pero, curiosamente, tiene poco efecto en la velocidad de InnoDB. subSelect.png

Código:

myisam_times = [] innodb_times = [] myisam_times_2 = [] innodb_times_2 = [] def subSelectRecordsIndexed(testTable,testSubSelect): selectString = "SELECT * FROM " + testTable + " WHERE index_col in ( SELECT index_col FROM " + testSubSelect + " )" cur.execute(selectString) setupString = "from __main__ import subSelectRecordsIndexed" def subSelectRecordsNotIndexed(testTable,testSubSelect): selectString = "SELECT * FROM " + testTable + " WHERE index_col in ( SELECT non_index_col FROM " + testSubSelect + " )" cur.execute(selectString) setupString2 = "from __main__ import subSelectRecordsNotIndexed" # Truncate the old tables, and re-fill with 1000000 records truncateString = "TRUNCATE test_table_innodb" truncateString2 = "TRUNCATE test_table_myisam" cur.execute(truncateString) cur.execute(truncateString2) lengthOfTable = 1000000 # Fill up the tables with random data for x in xrange(lengthOfTable): rand1 = random.random() rand2 = random.random() rand3 = random.random() rand4 = random.random() insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")" cur.execute(insertString) cur.execute(insertString2) for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]: truncateString = "TRUNCATE subselect_innodb" truncateString2 = "TRUNCATE subselect_myisam" cur.execute(truncateString) cur.execute(truncateString2) # For each length, empty the table and re-fill it with random data rand_sample = sorted(random.sample(xrange(lengthOfTable), theLength)) rand_sample_2 = random.sample(xrange(lengthOfTable), theLength) for (the_value_1,the_value_2) in zip(rand_sample,rand_sample_2): insertString = "INSERT INTO subselect_innodb (index_col,non_index_col) VALUES (" + str(the_value_1) + "," + str(the_value_2) + ")" insertString2 = "INSERT INTO subselect_myisam (index_col,non_index_col) VALUES (" + str(the_value_1) + "," + str(the_value_2) + ")" cur.execute(insertString) cur.execute(insertString2) db.commit() # Finally, time the queries innodb_times.append( timeit.timeit(''subSelectRecordsIndexed("test_table_innodb","subselect_innodb")'', number=100, setup=setupString) ) myisam_times.append( timeit.timeit(''subSelectRecordsIndexed("test_table_myisam","subselect_myisam")'', number=100, setup=setupString) ) innodb_times_2.append( timeit.timeit(''subSelectRecordsNotIndexed("test_table_innodb","subselect_innodb")'', number=100, setup=setupString2) ) myisam_times_2.append( timeit.timeit(''subSelectRecordsNotIndexed("test_table_myisam","subselect_myisam")'', number=100, setup=setupString2) )

Creo que el mensaje para llevar a casa de todo esto es que si está realmente preocupado por la velocidad, debe hacer una evaluación comparativa de las consultas que está realizando en lugar de hacer suposiciones sobre qué motor será más adecuado.

Para una carga con más escrituras y lecturas, se beneficiará de InnoDB. Debido a que InnoDB proporciona el bloqueo de filas en lugar del bloqueo de tabla, su SELECT puede ser concurrente, no solo entre sí sino también con muchos INSERT . Sin embargo, a menos que tenga la intención de utilizar transacciones de SQL, establezca el flujo de confirmación InnoDB en 2 ( innodb_flush_log_at_trx_commit ). Esto le devuelve una gran cantidad de rendimiento en bruto que de otro modo perdería al mover tablas de MyISAM a InnoDB.

También, considere agregar la replicación. Esto le da un poco de escalado de lectura y, como indicó que sus lecturas no tienen que estar actualizadas, puede dejar que la replicación quede un poco retrasada. Solo asegúrese de que pueda alcanzar cualquier cosa que no sea el tráfico más intenso o siempre estará atrasado y nunca lo hará. Sin embargo, si sigue este camino, le recomiendo encarecidamente que aísle la lectura de los esclavos y la administración del retraso de replicación a su controlador de base de datos. Es mucho más simple si el código de la aplicación no lo sabe.

Por último, ten en cuenta las diferentes cargas de la mesa. No tendrá la misma proporción de lectura / escritura en todas las tablas. Algunas mesas más pequeñas con lecturas cercanas al 100% podrían permitirse permanecer en MyISAM. Del mismo modo, si tiene algunas tablas que están cerca del 100% de escritura, puede beneficiarse de INSERT DELAYED , pero eso solo se admite en MyISAM (la cláusula DELAYED se ignora para una tabla InnoDB).

Pero el punto de referencia para estar seguro.

Si utiliza MyISAM, no realizará ninguna transacción por hora, a menos que considere que cada declaración DML es una transacción (que, en cualquier caso, no será duradera ni atómica en caso de un fallo).

Por lo tanto creo que tienes que usar InnoDB.

300 transacciones por segundo suena bastante. Si absolutamente necesita que estas transacciones sean duraderas en todos los fallos de alimentación, asegúrese de que su subsistema de E / S pueda manejar esta cantidad de escrituras por segundo fácilmente. Necesitará al menos un controlador RAID con caché respaldada por batería.

Si puede recibir un pequeño golpe de durabilidad, puede usar InnoDB con innodb_flush_log_at_trx_commit configurado en 0 o 2 (consulte la documentación para obtener más información), puede mejorar el rendimiento.

Hay una serie de parches que pueden aumentar la concurrencia de Google y otros; estos pueden ser interesantes si aún no puede obtener el rendimiento suficiente sin ellos.

Un poco fuera de tema, pero para fines de documentación y exhaustividad, me gustaría agregar lo siguiente.

En general, el uso de InnoDB resultará en una aplicación mucho MENOS compleja, probablemente también más libre de errores. Debido a que puede poner toda la integridad referencial (restricciones de clave externa) en el modelo de datos, no necesita el código de la aplicación que necesitará con MyISAM.

Cada vez que inserte, elimine o reemplace un registro, TENDRÁ que verificar y mantener las relaciones. Por ejemplo, si elimina un padre, todos los hijos también deben eliminarse. Por ejemplo, incluso en un sistema simple de blogs, si elimina un registro de publicación de blog, tendrá que eliminar los registros de comentarios, los "me gusta", etc. En InnoDB, el motor de la base de datos lo hace automáticamente (si especificó las restricciones en el modelo). ) y no requiere código de aplicación. En MyISAM, esto tendrá que ser codificado en la aplicación, lo cual es muy difícil en los servidores web. Los servidores web son por naturaleza muy concurrentes / paralelos y debido a que estas acciones deben ser atómicas y MyISAM no admite transacciones reales, el uso de MyISAM para servidores web es riesgoso / propenso a errores.

También en la mayoría de los casos, InnoDB se desempeñará mucho mejor, por múltiples razones, una de ellas es que puede usar el bloqueo de nivel de registro en lugar del bloqueo de nivel de tabla. No solo en una situación donde las escrituras son más frecuentes que las lecturas, también en situaciones con uniones complejas en grandes conjuntos de datos. Notamos un aumento del rendimiento de 3 veces solo al usar tablas InnoDB sobre las tablas MyISAM para uniones muy grandes (tomar varios minutos).

Yo diría que en general InnoDB (el uso de un modelo de datos 3NF completo con integridad referencial) debería ser la opción predeterminada cuando se usa MySQL. MyISAM solo debe utilizarse en casos muy específicos. Lo más probable es que se desempeñe menos, lo que resultará en una aplicación más grande y con más errores.

Habiendo dicho ésto. Datamodelling es un arte que rara vez se encuentra entre los diseñadores / programadores web. Sin ofender, pero explica que MyISAM haya sido usado tanto.

Un poco tarde para el juego ... pero aquí hay una publicación bastante completa que escribí hace unos meses , detallando las principales diferencias entre MYISAM e InnoDB. Toma una taza de té (y quizás una galleta) y disfruta.

La principal diferencia entre MyISAM e InnoDB es la integridad referencial y las transacciones. También hay otras diferencias, como bloqueo, retrotracción y búsquedas de texto completo.

Integridad referencial

La integridad referencial asegura que las relaciones entre las tablas permanezcan consistentes. Más específicamente, esto significa que cuando una tabla (por ejemplo, Listados) tiene una clave externa (por ejemplo, ID de producto) que apunta a una tabla diferente (por ejemplo, Productos), cuando se producen actualizaciones o eliminaciones en la tabla a la que se hace referencia, estos cambios se conectan en cascada al enlace mesa. En nuestro ejemplo, si se cambia el nombre de un producto, las claves externas de la tabla de enlace también se actualizarán; Si se elimina un producto de la tabla "Productos", también se eliminarán todos los listados que apuntan a la entrada eliminada. Además, cualquier listado nuevo debe tener esa clave externa que apunta a una entrada válida y existente.

InnoDB es un DBMS relacional (RDBMS) y, por lo tanto, tiene integridad referencial, mientras que MyISAM no.

Transacciones y Atomicidad

Los datos de una tabla se administran mediante declaraciones en lenguaje de manipulación de datos (DML), como SELECT, INSERT, UPDATE y DELETE. Una transacción agrupa dos o más declaraciones DML en una sola unidad de trabajo, por lo que se aplica la unidad completa o ninguna de ellas.

MyISAM no admite transacciones, mientras que InnoDB sí lo hace.

Si se interrumpe una operación mientras se usa una tabla MyISAM, la operación se cancela de inmediato, y las filas (o incluso los datos dentro de cada fila) afectados se verán afectadas, incluso si la operación no se completó.

Si se interrumpe una operación mientras se usa una tabla InnoDB, ya que utiliza transacciones, que tienen atomicidad, cualquier transacción que no se completó no entrará en vigencia, ya que no se realiza ninguna confirmación.

Bloqueo de tabla vs bloqueo de fila

Cuando una consulta se ejecuta en una tabla MyISAM, la tabla completa en la que se consulta se bloqueará. Esto significa que las consultas subsiguientes solo se ejecutarán una vez finalizada la actual. Si está leyendo una tabla grande, y / o hay operaciones frecuentes de lectura y escritura, esto puede significar una enorme acumulación de consultas.

Cuando una consulta se ejecuta en una tabla InnoDB, solo se bloquean las filas involucradas, el resto de la tabla permanece disponible para las operaciones CRUD. Esto significa que las consultas pueden ejecutarse simultáneamente en la misma tabla, siempre que no usen la misma fila.

Esta característica en InnoDB se conoce como concurrencia. Si bien la concurrencia es grande, hay un gran inconveniente que se aplica a un rango selecto de tablas, ya que hay una sobrecarga al cambiar entre los subprocesos del núcleo, y debe establecer un límite en los hilos del núcleo para evitar que el servidor se detenga. .

Transacciones y Rollbacks

Cuando ejecuta una operación en MyISAM, se establecen los cambios; en InnoDB, esos cambios se pueden revertir. Los comandos más comunes que se utilizan para controlar las transacciones son COMMIT, ROLLBACK y SAVEPOINT. 1. COMPROMISO: puede escribir múltiples operaciones DML, pero los cambios solo se guardarán cuando se realice un COMPROMISO 2. ROLLBACK: puede descartar cualquier operación que aún no se haya confirmado 3. SAVEPOINT: establece un punto en la lista de operaciones a las que una operación ROLLBACK puede revertir a

Confiabilidad

MyISAM no ofrece integridad de datos: los fallos de hardware, las paradas impuras y las operaciones canceladas pueden provocar que los datos se dañen. Esto requeriría la reparación completa o la reconstrucción de los índices y tablas.

InnoDB, por otro lado, utiliza un registro transaccional, un búfer de doble escritura y una suma de comprobación y validación automáticas para evitar la corrupción. Antes de que InnoDB realice cambios, registra los datos antes de las transacciones en un archivo de espacio de tabla del sistema llamado ibdata1. Si se produce un bloqueo, InnoDB se recuperará automáticamente a través de la reproducción de esos registros.

FULLTEXT Indexación

InnoDB no admite la indexación FULLTEXT hasta la versión 5.6.4 de MySQL. En el momento de escribir este post, la versión de MySQL de muchos proveedores de alojamiento compartido todavía está por debajo de 5.6.4, lo que significa que la indexación FULLTEXT no es compatible con las tablas InnoDB.

Sin embargo, esta no es una razón válida para usar MyISAM. Es mejor cambiar a un proveedor de alojamiento que admita versiones actualizadas de MySQL. No es que una tabla MyISAM que utiliza la indexación FULLTEXT no se pueda convertir en una tabla InnoDB.

Conclusión

En conclusión, InnoDB debería ser su motor de almacenamiento predeterminado de elección. Elija MyISAM u otros tipos de datos cuando satisfagan una necesidad específica.

La pregunta y la mayoría de las respuestas están desactualizadas .

Sí, es un cuento de viejas que MyISAM es más rápido que InnoDB. note la fecha de la Cuestión: 2008; Ahora es casi una década después. InnoDB ha logrado avances significativos en el rendimiento desde entonces.

El gráfico dramático fue para el caso donde gana MyISAM: COUNT(*) sin una WHEREcláusula. ¿Pero es eso realmente lo que te dedicas a hacer?

Si ejecuta la prueba de concurrencia , es muy probable que InnoDB gane, incluso contraMEMORY .

Si realiza cualquier escritura mientras realiza una evaluación comparativa SELECTs, MEMORYes posible que MyISAM pierda debido al bloqueo a nivel de tabla.

De hecho, Oracle está tan seguro de que InnoDB es mejor que casi han eliminado MyISAM de 8.0.

La pregunta fue escrita temprano en los días de 5.1. Desde entonces, estas versiones principales se marcaron como "Disponibilidad general":

  • 2010: 5.5 (.8 en diciembre)
  • 2013: 5.6 (.10 en febrero).
  • 2015: 5.7 (.9 en octubre).
  • 2018: 8.0 (.11 en abril)

En pocas palabras: no use MyISAM

MYISAM:

  1. MYISAM admite el bloqueo a nivel de tabla

  2. MyISAM diseñado para la necesidad de velocidad

  3. MyISAM no admite claves externas, por lo que llamamos MySQL con MYISAM es DBMS
  4. MyISAM almacena sus tablas, datos e índices en el espacio en disco utilizando tres archivos diferentes separados. (nombre de tabla.FRM, nombre de tabla.MYD, nombre de tabla.MYI)
  5. MYISAM no admite transacciones. No se puede cometer y deshacer con MYISAM. Una vez que se emite un comando se hace.

INNODB:

  1. InnoDB admite el bloqueo a nivel de fila
  2. InnoDB diseñado para obtener el máximo rendimiento al procesar grandes volúmenes de datos
  3. InnoDB admite claves externas, por lo que llamamos MySQL con InnoDB es RDBMS
  4. InnoDB almacena sus tablas e índices en un espacio de tablas
  5. InnoDB soporta transacciones. Puedes cometer y revertir con InnoDB.

MyISAM

El MyISAM enginees el motor predeterminado en la mayoría de MySQLlas instalaciones y es un derivado del tipo de motor ISAM original de apoyo en las primeras versiones del sistema de MySQL. El motor proporciona la mejor combinación de rendimiento y funcionalidad, aunque carece de capacidades de transacción (use los motores InnoDBo BDB) y usos table-level locking.

FlashMAX y FlashMAX Connect: liderando la transformación de la plataforma Flash Descargar ahora A menos que necesite transacciones, hay pocas bases de datos y aplicaciones que no pueden almacenarse de manera efectiva con el motor MyISAM. Sin embargo, las aplicaciones de muy alto rendimiento donde hay un gran número de inserciones / actualizaciones de datos en comparación con el número de lecturas pueden causar problemas de rendimiento para el motor MyISAM. Originalmente se diseñó con la idea de que más del 90% del acceso de la base de datos a una tabla MyISAM se leería, en lugar de escribir.

Con el bloqueo a nivel de tabla, una base de datos con un alto número de inserciones o actualizaciones de fila se convierte en un cuello de botella en el rendimiento, ya que la tabla se bloquea mientras se agregan los datos. Afortunadamente, esta limitación también funciona bien dentro de las restricciones de una base de datos que no es de transacciones.

MyISAM Summary

Nombre -MyISAM

Introducido -v3.23

Instalación predeterminada -Sí

Limitaciones de datos -Ninguno

Limitaciones del índice -64 índices por tabla (32 pre 4.1.2); Max 16 columnas por índice

Soporte de transacciones -No

Nivel de bloqueo -Tabla

InnoDB

El InnoDB Enginese proporciona por Innobase Oyy soporta toda la funcionalidad de base de datos (y más) de motor MyISAM y también añade capacidades de transacción completo (con plena ACID(Atomicidad, Consistencia, Aislamiento y Durabilidad) el cumplimiento) y bloqueo a nivel de fila de datos.

La clave del sistema InnoDB es una estructura de base de datos, almacenamiento en caché e indexación en la que los índices y los datos se almacenan en la memoria caché, así como el almacenamiento en disco. Esto permite una recuperación muy rápida, y funciona incluso en conjuntos de datos muy grandes. Al admitir el bloqueo de nivel de fila, puede agregar datos a una tabla InnoDB sin que el motor bloquee la tabla con cada inserción y esto acelera tanto la recuperación como el almacenamiento de información en la base de datos.

Al igual que con MyISAM, hay pocos tipos de datos que no se pueden almacenar de manera efectiva en una base de datos InnoDB. De hecho, no hay razones importantes por las que no siempre se debe usar una base de datos InnoDB. La sobrecarga de administración para InnoDBes un poco más onerosa, y obtener la optimización adecuada para los tamaños de memoria caché y en cachés de disco y archivos de base de datos puede ser complejo al principio. Sin embargo, también significa que obtiene más flexibilidad sobre estos valores y una vez establecidos, los beneficios de rendimiento pueden superar fácilmente el tiempo inicial empleado. Alternativamente, puede dejar que se MySQLgestione esto automáticamente por usted.

Si está dispuesto (y puede) a configurar los ajustes de InnoDB para su servidor, le recomendaría que dedique tiempo a optimizar la configuración de su servidor y luego utilice el motor InnoDB como predeterminado.

InnoDB Summary

Nombre -InnoDB

Se introdujo -v3.23 (solo fuente), v4.0 (fuente y binario)

Instalación predeterminada -No

Limitaciones de datos -Ninguno

Limitaciones del índice -Ninguno

Soporte de transacciones -Sí (compatible con ACID)

Nivel de bloqueo

Tenga en cuenta que mi educación y experiencia formal es con Oracle, mientras que mi trabajo con MySQL ha sido completamente personal y en mi tiempo libre, por lo que si digo cosas que son ciertas para Oracle pero no lo son para MySQL, me disculpo. Si bien los dos sistemas comparten mucho, la teoría relacional / álgebra es la misma, y ​​las bases de datos relacionales son todavía bases de datos relacionales, ¡todavía hay muchas diferencias!

Me gusta especialmente (así como el bloqueo a nivel de fila) que InnoDB se basa en transacciones, lo que significa que puede estar actualizando / insertando / creando / alterando / eliminando / etc varias veces para una "operación" de su aplicación web. El problema que surge es que si solo se comprometen algunos de esos cambios / operaciones, pero otros no, la mayoría de las veces (dependiendo del diseño específico de la base de datos) terminará con una base de datos con datos / estructura en conflicto.

Nota: Con Oracle, las declaraciones create / alter / drop se denominan declaraciones "DDL" (definición de datos), y activan implícitamente un commit. Las declaraciones de inserción / actualización / eliminación, llamadas "DML" (manipulación de datos), no se confirman automáticamente, sino solo cuando se realiza un DDL, confirmación o salida / salida (o si configura su sesión como "confirmación automática", o Si su cliente se compromete automáticamente. Es imperativo tenerlo en cuenta al trabajar con Oracle, pero no estoy seguro de cómo MySQL maneja los dos tipos de declaraciones. Debido a esto, quiero dejar claro que no estoy seguro de esto cuando se trata de MySQL; Sólo con Oracle.

Un ejemplo de cuando los motores basados ​​en transacciones sobresalen:

Digamos que yo o usted está en una página web para inscribirse para asistir a un evento gratuito, y uno de los propósitos principales del sistema es permitir que solo se inscriban hasta 100 personas, ya que ese es el límite de asientos. Para el evento. Una vez que se alcanzan los 100 registros, el sistema deshabilitará más registros, al menos hasta que otros se cancelen.

En este caso, puede haber una mesa para invitados (nombre, teléfono, correo electrónico, etc.) y una segunda mesa que rastrea el número de invitados que se han registrado. Por lo tanto, tenemos dos operaciones para una "transacción". Ahora suponga que después de que la información del invitado se agrega a la tabla HUÉSPEDES, hay una pérdida de conexión o un error con el mismo impacto. La tabla GUESTS se actualizó (insertó en), pero la conexión se perdió antes de que se pudieran actualizar los "asientos disponibles".

Ahora tenemos un invitado agregado a la tabla de invitados, pero el número de asientos disponibles ahora es incorrecto (por ejemplo, el valor es 85 cuando en realidad es 84).

Por supuesto, hay muchas maneras de manejar esto, como rastrear los asientos disponibles con "100 menos el número de filas en la tabla de invitados" o algún código que verifique que la información sea consistente, etc. ... Pero con una base de datos basada en transacciones motor como InnoDB, TODAS las operaciones están comprometidas, o NINGUNAS de ellas están comprometidas . Esto puede ser útil en muchos casos, pero como dije, no es la ÚNICA manera de estar seguro, no (una buena forma, sin embargo, manejada por la base de datos, no por el programador / guionista).

Eso es todo "basado en transacciones" esencialmente significa en este contexto, a menos que me esté perdiendo algo: que o bien toda la transacción tenga éxito como debería, o que no se cambie nada , ya que hacer solo cambios parciales puede hacer una pequeña PARADA en el desastre. Base de datos, tal vez incluso corrompiéndolo ...

Pero lo diré una vez más, no es la única manera de evitar hacer un desastre. Pero es uno de los métodos que maneja el motor en sí mismo, lo que le permite usar el código / secuencia de comandos y solo tiene que preocuparse por "si la transacción fue exitosa o no, y qué debo hacer si no (como reintentar), en lugar de hacerlo manualmente. escribir código para verificarlo "manualmente" desde fuera de la base de datos, y hacer mucho más trabajo para tales eventos.

Por último, una nota sobre el bloqueo de tablas frente al bloqueo de filas:

DESCARGO DE RESPONSABILIDAD: Puedo estar equivocado en todo lo que sigue con respecto a MySQL, y las situaciones hipotéticas / de ejemplo son cosas a considerar, pero puedo estar equivocado en lo que es exactamente posible causar corrupción con MySQL. Sin embargo, los ejemplos son muy reales en la programación general, incluso si MySQL tiene más mecanismos para evitar tales cosas ...

De todos modos, estoy bastante seguro de estar de acuerdo con aquellos que han argumentado que el número de conexiones se permiten a la vez no no trabajar en torno a una tabla bloqueada. De hecho, las conexiones múltiples son todo el punto de bloquear una mesa. Para que otros procesos / usuarios / aplicaciones no puedan corromper la base de datos al hacer cambios al mismo tiempo.

¿Cómo dos o más conexiones que trabajan en la misma fila te hacen un día realmente malo? Supongamos que hay dos procesos que desean / necesitan actualizar el mismo valor en la misma fila, digamos porque la fila es un registro de un recorrido en autobús, y cada uno de los dos procesos simultáneamente desea actualizar los "riders" o "available_seats" campo como "el valor actual más 1."

Hagámoslo hipotéticamente, paso a paso:

  1. El proceso uno lee el valor actual, digamos que está vacío, por lo tanto, ''0'' hasta ahora.
  2. El proceso dos también lee el valor actual, que todavía es 0.
  3. Proceso uno escribe (actual + 1) que es 1.
  4. El proceso dos debe escribir 2, pero como lee el valor actual antes de procesar uno, escribe el nuevo valor, también escribe 1 en la tabla.

No estoy seguro de que dos conexiones puedan mezclarse de esa manera, ambas leen antes de que la primera escriba ... Pero si no, entonces todavía vería un problema con:

  1. El proceso uno lee el valor actual, que es 0.
  2. Proceso uno escribe (actual + 1), que es 1.
  3. El proceso dos lee el valor actual ahora. Pero mientras se procesa una escritura DID (actualización), no ha confirmado los datos, por lo tanto, solo ese mismo proceso puede leer el nuevo valor que se actualizó, mientras que todos los demás ven el valor anterior, hasta que hay un compromiso.

Además, al menos con las bases de datos de Oracle, hay niveles de aislamiento, que no perderé el tiempo intentando parafrasear. Aquí hay un buen artículo sobre ese tema, y ​​cada nivel de aislamiento tiene sus pros y sus contras, lo que estaría de acuerdo con la importancia de los motores basados ​​en transacciones en una base de datos ...

Por último, es probable que existan diferentes medidas de seguridad dentro de MyISAM, en lugar de claves externas e interacción basada en transacciones. Bueno, por un lado, está el hecho de que una tabla entera está bloqueada, lo que hace que sea menos probable que se necesiten transacciones / FK .

Y, por desgracia, si está al tanto de estos problemas de concurrencia, sí, puede jugar con menos seguridad y simplemente escribir sus aplicaciones, configurar sus sistemas para que tales errores no sean posibles (su código es responsable, en lugar de la base de datos en sí). Sin embargo, en mi opinión, diría que siempre es mejor utilizar tantas salvaguardas como sea posible, programar a la defensiva y estar siempre consciente de que es imposible evitar por completo el error humano. Les sucede a todos, y cualquiera que diga que es inmune a eso debe estar mintiendo, o no ha hecho más que escribir una aplicación / script "Hello World". ;-)

Espero que algo de eso sea útil para alguien, y más aún, ¡espero que no solo haya sido el culpable de las suposiciones y el hecho de ser un humano por error! Mis disculpas si es así, pero es bueno pensar en los ejemplos, investigar el riesgo de, etc., incluso si no son potenciales en este contexto específico.

Siéntete libre de corregirme, edita esta "respuesta", incluso vota abajo. Solo intenta mejorar, en lugar de corregir una mala suposición mía con otra. ;-)

Esta es mi primera respuesta, así que, por favor, perdone la extensión debido a todos los descargos de responsabilidad, etc ... ¡No quiero sonar arrogante cuando no estoy absolutamente seguro!

Cada aplicación tiene su propio perfil de rendimiento para el uso de una base de datos, y es probable que cambie con el tiempo.

Lo mejor que puedes hacer es probar tus opciones. Cambiar entre MyISAM e InnoDB es trivial, así que cargue algunos datos de prueba y dispare jmeter contra su sitio y vea qué sucede.

Casi siempre que comienzo un nuevo proyecto, busco esta misma pregunta en Google para ver si se me ocurren nuevas respuestas.

Eventualmente se reduce a: tomo la última versión de MySQL y hago pruebas.

Tengo tablas donde quiero hacer búsquedas de clave / valor ... y eso es todo. Necesito obtener el valor (0-512 bytes) para una clave hash. No hay muchas transacciones en este DB. La tabla recibe actualizaciones de vez en cuando (en su totalidad), pero 0 transacciones.

Entonces, no estamos hablando de un sistema complejo, estamos hablando de una búsqueda simple, y de cómo (además de hacer que la tabla sea la memoria RAM) podemos optimizar el rendimiento.

También hago pruebas en otras bases de datos (es decir, NoSQL) para ver si hay algún lugar donde pueda obtener una ventaja. La mayor ventaja que he encontrado está en el mapeo de claves, pero en lo que respecta a la búsqueda, MyISAM actualmente está superando a todos.

Aunque no realizaría transacciones financieras con tablas MyISAM, pero para búsquedas simples, debería probarlo. Normalmente, 2 veces a 5 veces las consultas / seg.

Pruébalo, doy la bienvenida al debate.

En resumen, InnoDB es bueno si está trabajando en algo que necesita una base de datos confiable que pueda manejar muchas instrucciones de INSERTAR y ACTUALIZAR.

y, MyISAM es bueno si necesita una base de datos que en su mayoría llevará muchas instrucciones de lectura (SELECCIONAR) en lugar de escribir (INSERTAR y ACTUALIZAR), considerando su inconveniente en el tema de bloqueo de tablas.

es posible que desee retirar
Pros y contras de InnoDB
Pros y contras de MyISAM

Resultado final: si está trabajando fuera de línea con selecciones en grandes porciones de datos, MyISAM probablemente le dará velocidades mejores (mucho mejores).

hay algunas situaciones en las que MyISAM es infinitamente más eficiente que InnoDB: al manipular grandes volcados de datos fuera de línea (debido al bloqueo de tablas).

ejemplo: estaba convirtiendo un archivo csv (15M registros) de NOAA que usa campos VARCHAR como claves. InnoDB tardaba muchísimo, incluso con grandes trozos de memoria disponibles.

Este es un ejemplo del csv (los campos primero y tercero son claves).

USC00178998,20130101,TMAX,-22,,,7,0700 USC00178998,20130101,TMIN,-117,,,7,0700 USC00178998,20130101,TOBS,-28,,,7,0700 USC00178998,20130101,PRCP,0,T,,7,0700 USC00178998,20130101,SNOW,0,T,,7,

ya que lo que necesito hacer es ejecutar una actualización por lotes fuera de línea de los fenómenos meteorológicos observados, uso la tabla MyISAM para recibir datos y ejecute UNIONES en las teclas para poder limpiar el archivo entrante y reemplazar los campos VARCHAR con teclas INT Tablas externas donde se almacenan los valores originales de VARCHAR).

Sé que esto no será popular pero aquí va:

myISAM carece de soporte para los elementos esenciales de la base de datos, como las transacciones y la integridad referencial, que a menudo dan como resultado aplicaciones con errores / fallos. No puede no aprender los fundamentos de diseño de base de datos adecuados si ni siquiera son compatibles con su motor de base de datos.

No usar la integridad referencial o las transacciones en el mundo de la base de datos es como no usar la programación orientada a objetos en el mundo del software.

¡InnoDB existe ahora, usa eso en su lugar! Incluso los desarrolladores de MySQL finalmente han aceptado cambiar esto al motor predeterminado en las versiones más nuevas, a pesar de que myISAM es el motor original que era el predeterminado en todos los sistemas heredados.

No, no importa si estás leyendo o escribiendo o qué consideraciones de rendimiento tienes, usar myISAM puede dar lugar a una variedad de problemas, como el que acabo de encontrar: estaba realizando una sincronización de base de datos y al mismo tiempo alguien más Accedí a una aplicación que accedió a una tabla establecida en myISAM. Debido a la falta de soporte de transacciones y la poca fiabilidad de este motor, ¡esto colapsó toda la base de datos y tuve que reiniciar manualmente mysql!

Durante los últimos 15 años de desarrollo, he usado muchas bases de datos y motores. myISAM se estrelló conmigo una docena de veces durante este período, ¡otras bases de datos, solo una vez! Y esa fue una base de datos Microsoft SQL donde un desarrollador escribió un código CLR defectuoso (tiempo de ejecución de lenguaje común, básicamente un código C # que se ejecuta dentro de la base de datos), por cierto, no fue culpa del motor de la base de datos exactamente.

Estoy de acuerdo con las otras respuestas aquí que dicen que las aplicaciones de calidad, alta disponibilidad y alto rendimiento no deben usar myISAM ya que no funcionará, no es lo suficientemente robusta o estable como para dar como resultado una experiencia sin frustraciones. Vea la respuesta de Bill Karwin para más detalles.

PD: Me encanta cuando los fanáticos de myISAM votan a favor, pero no puedo decirte qué parte de esta respuesta es incorrecta.

Si es 70% de inserciones y 30% de lecturas, entonces es más como en el lado de InnoDB.

También puedes ver algunos reemplazos para MySQL:

Mariadb

http://mariadb.org/

MariaDB es un servidor de base de datos que ofrece una funcionalidad de reemplazo para MySQL. MariaDB está construida por algunos de los autores originales de MySQL, con la asistencia de la comunidad más amplia de desarrolladores de software de código abierto y gratuito. Además de la funcionalidad principal de MySQL, MariaDB ofrece un amplio conjunto de mejoras de funciones que incluyen motores de almacenamiento alternativos, optimizaciones de servidor y parches.

Servidor Percona

https://launchpad.net/percona-server

Un reemplazo mejorado para MySQL, con mejor rendimiento, diagnósticos mejorados y funciones adicionales.

myisam es un NOGO para ese tipo de carga de trabajo (escrituras de alta concurrencia), no tengo mucha experiencia con innodb (lo probé 3 veces y descubrí que en cada caso el rendimiento fue malo, pero ha pasado un tiempo desde la última prueba) no está obligado a ejecutar mysql, considere probar postgres ya que maneja escrituras concurrentes MUCHO mejor

En mi experiencia, MyISAM fue una mejor opción siempre que no haga BORRADAS, ACTUALIZACIONES, una gran cantidad de INSERTOS individuales, transacciones e indexación de texto completo. Por cierto, la tabla de verificación es horrible. A medida que la tabla envejece en términos de la cantidad de filas, no se sabe cuándo terminará.

Intenté ejecutar la inserción de datos aleatorios en las tablas MyISAM e InnoDB. El resultado fue bastante impactante. ¡MyISAM necesitó unos segundos menos para insertar 1 millón de filas que InnoDB por solo 10 mil!

Me he dado cuenta de que, aunque Myisam tiene contención de bloqueo, aún es más rápido que InnoDb en la mayoría de los escenarios debido al rápido esquema de adquisición de bloqueo que utiliza. He intentado varias veces Innodb y siempre recurro a MyIsam por una razón u otra. También InnoDB puede ser muy intensivo en CPU en grandes cargas de escritura.

Para esa proporción de lectura / escritura, supongo que InnoDB tendrá un mejor desempeño. Ya que está bien con las lecturas sucias, podría (si se lo permite) replicar a un esclavo y dejar que todas sus lecturas vayan al esclavo. Además, considere la posibilidad de insertar en volumen, en lugar de un registro a la vez.