A huge used database reverberate on a more fragmented database even if you delete any large data. The data base admin should optimize and take care of this especially if dealing with a lot of varying characters (VARCHAR).

At this article I will explain how to opmimize MySQL databases with tools that mysql provides. I will separate on two cases:

• Optimizing just one table
• Optimizing all the tables on a database

The main disvantage is that you can only optimize MyISAM, InnoDB, and ARCHIVE tables.

Read the rest of this entry »

En el desarrollo de aplicaciones contra bases de datos, la mayoría de las veces, necesitas unos valores de referencia para saber si las consultas o instrucciones que está procesando tu aplicación se están comportando como debiere. También si te toca administrar un servidor de bd y monitorearlo este post te será de gran ayuda.

En este sentido escribiré algunos de los parámetros que podemos monitorear para el caso de bases de datos MySQL.

Básicamente MySQL nos proporciona una serie de instrucciones SQL que nos devuelve información de estado y rendimiento del servidor, para que luego las evaluemos y decidamos que acción pertinente se lleva a cabo.

La instrucción básica que se usa en MySQL es

SHOW STATUS;

la cual nos devuelve una cantidad importante de estados de variables. Aquí explico las más importantes.

Threads_connected

Esta variable indica el número total de clientes que tienen una conexión abierta actualmente con el servidor.
Proporciona información en tiempo real de cuantos clientes están conectados con el servidor. Esto puede ser de ayuda para analizar el tráfico o decidir cuando es el mejor instante para reiniciar un servidor.

Created_tmp_disk_tables

Esta variable indica el número de tablas temporales que han sido creadas en disco frente a hacerlo en memoria.
El acceso a tablas en disco normalmente es más lento que acceder a ellas en memoria. Por tanto las consultas que usan la sintaxis CREATE TEMPORARY TABLE son más lentas si el valor de la esta variable es superior.

Read the rest of this entry »

Es algo común que estés desarrollando contra un gestor de bases de datos de “juguete” como puede ser sqlite3 y en un momento dado querer pasar a uno “de verdad” para probar cuanto rendimiento tiene tu app.

En este caso y como reza el título explico como hacer la migración de sqlite3 a MySQL, que resulta bastante trivial.

SQLite a MySql

1. Se hace un dump de la bbdd que queremos

sqlite3 BasedeDatosaExportar .dump .quit >fichero-dump.sql

2. Ahora toca adaptarla a la sintaxis expecial de MySQL
   - Reemplazar ” (comillas dobles) por ` (acento grave)
   - Elimina “BEGIN TRANSACTION;” “COMMIT;“, y las líneas “sqlite_sequence”
   - Substituye “autoincrement” con “auto_increment“
3. Y el fichero ya está listo para importar en MySQL.

Facil y bonito oye.

Muchas veces cuando estás trabajando con aplicaciones web o standalone que trabajan contra Bases de datos te ves en la necesidad de hacer un volcado de tu BD para hacer un backup o para migrar la aplicación. El problema es que en Mysql y con columnas con tipos de datos text o varchar que continen datos con caracteres especiales como á, ó, ç o ñ, letras acentuadas, etc. al hacer el volcado descubres que aparecen simbolos extraños. Por ejemplo

'paseos'

resulta en un

âpaseosâ

en la base de datos y que escribe al renderizarlo un feo

€™paseos’

Esto se supone que es un problema popular cuando se está moviendo de MySQL 4.0 a 4.1 o posteriores, pero también aparece cuando estás moviendo los datos de una base de datos a otra en la misma instalación de MySQL. El mover de una instalación 4.1 a otra 4.1 también da como resultado “los caracteres locos”. Y para más INRI, me ha tocado en alguna ocasión hacer backups de bases de datos críticas en MySQL 5 con los mismos resultados.

Read the rest of this entry »