La variable default_tmp_storage_engine se introdujo en 5.6.3, permitiendo la configuración del motor por defecto para las tablas temporales. Esto parece ir en la dirección, como he comentado con anterioridad, de convertir MyISAM en un motor opcional. En 5.7, se crea un espacio de tablas separado para guardar estas tablas con el objetivo de reducir su impacto en el rendimiento (esas tablas no tienen se rehacerse si el servidor falla de manera inesperada, por lo que se evitan escrituras extra).

Sin embargo, he visto mucha gente que asumía que porque el valor por defecto de default_tmp_storage_engine es “InnoDB”, todas las tablas temporales se crean en formato InnoDB. Esto no es cierto: primero, …

Por supuesto, esto sólo es un título para llamar la atención. Por lo que yo sé no todas las tablas de sistema se pueden convertir a InnoDB todavía (por ejemplo, las tablas de privilegios), lo cual convierte la cabecera en técnicamente falsa. MyISAM es un motor muy simple, y eso tiene algunas ventajas inherentes (no hay carga extra debido a las transacciones, más fácil de “editar” manualmente, normalmente ocupa menos espacio en disco), pero también algunas desventajas bastante importantes: no es seguro en el caso de un cuelgue general, no hay claves foráneas, sólo bloqueos a nivel de tabla, problemas de consistencia, bugs en tablas muy grandes,… La versión 5.7.5 “Milestone 15”, presentada hoy en el Oracle Open World tiene …

InnoDB se convirtió en el motor de almacenamiento por defecto en MySQL 5.5. Era un paso lógico. Es un motor transaccional, escalable y con un rendimiento superior a MyISAM. Hay que recordar esa frase tan mítica... MyISAM es el lugar donde los datos van para morir. Pero ese cambio ha traído algunas consecuencias. Malas prácticas que en MyISAM no tenían ningún efecto visible en InnoDB pueden causar graves problemas.

Uno de ellos es dejar transacciones abiertas y olvidadas. Y no hablo de minutos o horas, si no días e incluso he llegado a ver semanas. Cuando te contactan y te dicen que hay un problema con alguno de estos síntomas:

• ibdata1 no para de crecer, nos vamos a quedar sin espacio en disco
• la base de datos funciona muy lenta y tenemos constantes errores de tiempo de espera agotado esperando bloqueos de filas

Ya casi tenemos claro donde está el problema. Un SHOW ENGINE …

Prácticamente todas las bases de datos tienen algo que generalmente se conoce como REDO LOG. MySQL también lo tiene (ib_logfile*) y hasta donde yo se toda base de datos con propiedades ACID lo tiene. La idea de este post es explicar cual es la utilidad de dicho log y que tamaño deberemos configurar para mejorar el rendimiento de nuestra base de datos.

¿Qué es este log?

Son dos ficheros (o más si tu lo configuras así) que funcionan de forma circular y secuencial. Imaginemos que tenemos A y B. InnoDB empieza escribiendo en A desde el inicio del fichero hasta el final. Una vez terminado con A comienza con B... y una vez terminado B vuelva a A reescribiendo los datos que en el hay. Por lo tanto, independientemente del número de ficheros que tengas configurado en innodb_log_files_in_group este actuará como uno solo. Por esa razón no se suele cambiar innodb_log_files_in_group pero si el tamaño total del …

Original post: http://anothermysqldba.blogspot.com/2013/05/oscommerce-mysql.html


Ha sido un tiempo desde que me miré al oscommerce paquete de software. Es una gran plataforma para la construcción de un almacén de la tela en línea.

Sin embargo, cuando le preguntan si está por encima "MySQL \ V5" o por debajo de ella comienza a ponerme nervioso. Al parecer no soy el único con la preocupación de que InnoDB debería ser el motor de almacenamiento de elección.

• …

Mucha gente cree erroneamente que gracias a la opción innodb-file-per-table te permite, como MyISAM, portar una tabla en binario de un servidor a otro de forma transparente o recuperar el backup de una tabla. El problema viene cuando realmente necesitan hacer uso de ese backup y no funciona como ellos esperaban.

Al contrario que con MyISAM, donde los ficheros de tablas MYD e MYI son independientes del resto y portables, todas las tablas de InnoDB dependen de un tablespace común donde se almacenan las definiciones de las tablas y además depende de los IDs de transacciones entre otras cosas. Por lo que, si restauras un .idb, no recuperarás los datos.

Todo esto se aplica a la versión original de MySQL, la desarrollada por Oracle. Pero Xtrabackup y Percona Server nos permite esquivar esta limitación y trabajar con los ficheros binarios como si se tratasen de tablas MyISAM, moviéndolas y restaurándolas de un servidor a otro. …

Cuando tienes un entorno activo-pasivo o montas un esclavo para las lecturas, el mayor problema que te puedes encontrar al poner los nuevos servidores en producción es que las cachés se encuentren frias (cold cache). Como dichos servidores no han recibido consultas, todas sus cachés, como query cache o innodb_buffer_pool se encuentran vacias y todas las consultas tendrán que ir a disco duro durante los primeros minutos u horas. En esos primeros instantes, el rendimiento de tu backend será pésimo.

Hasta ahora, para evitar en la medida de lo posible ese problema, se lanzaban SELECT contra las tablas que obligasen a leerse todas las filas. Eran consultas muy pesadas que tardaban mucho tiempo en ejecutarse y ralentizaban aún más el rendimiento, pero... no había otra solución. Un ejemplo de está solución se puede leer en el blog de Santi Saez …

InnoDB es uno de los motores de almacenamiento que incluye MySQL por defecto desde hace varias versiones, y a partir de la 5.5 va a ser el utilizado por defecto en decrimento de MyISAM. Su características principales son el soporte de transacciones, lo que permite una gestión de los bloqueos a nivel de tabla/fila mucho más inteligente, y también permite realizar backups incrementales en caliente, pero además tiene soporte de integridad referencial, por lo que podemos crear claves ajenas o foráneas entre tablas.

La versión de Drupal de alto rendimiento Presflow recomienda InnoDB como storage engine y Drupal 7 lo utiliza por defecto, …

A veces es necesario almacenar una gran cantidad de datos en MySQL, por ejemplo las típicas tablas con los logs del sistema, fichajes de empleados, estadísticas de correo, resultados de encuestas, etc.. Son tablas que aumentan constantemente y que nunca dejarán de hacerlo. Por otro lado son tablas que a pesar de almacenar tantos datos y ocupar tanto espacio no podremos eliminar, ya sea porque son necesarios o porque nuestro jefe sufre el Síndrome de Diógenes. En esos casos, cuya única función es el almacenamiento constante y la consulta esporádica, cosas como integridad referencial o transacciones nos importa bien poco. Lo que nos tiene que preocupar es el tamaño de la tabla y el espacio libre en disco duro.

Para este tipo de almacenamiento existe un engine que nos puede ayudar, Archive:

• Compresión de datos al vuelo según se van introduciendo
• Bloqueo a nivel de fila
• Autoincrementales …

Una de las formas para importar datos en MySQL es el comando LOAD DATA INFILE. Es más rápido que un dump, ya que se leen los datos en bruto, en lugar de sentencias SQL.

El tiempo de importación depende del motor que use la tabla, por ejemplo, MyISAM puede ser 40 times más rápido que Innodb. Vamos a probarlo:

Preparación

Voy a utilizar MySQL 5.1.36 (64 bits MacOS X) para hacer las pruebas. Necesitaré una tabla grande, así que partiré de la tabla City de la Base de datos world y crearé una tabla más grande que se llame “city_huge”:

CREATE TABLE city_huge LIKE CITY;

INSERT INTO city_huge 
    SELECT NULL, name, CountryCode, District, Population FROM city;
# Ejecuta 100 veces esta sentencia,
# así city_huge será 100 veces más grande que city.
# Un consejo, usa un script, una tabla temporal, …