Por tanto la creación de índices es de vital importancia para acelerar las consultas a base de datos, sobre todo cuando las tablas presentan un tamaño considerable. Pero los índices no son el remedio a todos los males, puesto que estos cambian cada vez que la columna asociada se modifica, no se deberían crear indices sobre columnas en las que son frecuentes las operaciones de escritura. También habrá que tener en cuenta que los índices ocupan espacio, en algunos caso más que la tabla a la que hacen referencia.

En MySQL hay cinco tipos de índices:

• PRIMARY KEY: Este índice se ha creado para generar consultas especialmente rápidas, debe ser único y no se admite el almacenamiento de NULL.
• KEY o INDEX: Son usados indistintamente por MySQL, permite crear indices sobre una columna, sobre varias columnas o sobre partes de una columna.
• UNIQUE: Este tipo de índice no permite el almacenamiento de valores iguales.
• FULLTEXT: Permiten realizar búsquedas de palabras. Sólo pueden usarse sobre columnas CHAR, VARCHAR o TEXT
• SPATIAL: Este tipo de índices solo puede usarse sobre columnas de datos geométricos (spatial) y en el motor MyISAM

1.- La caché de consultas: Cuando se recibe una consulta de tipo SELECT se ejecuta un algoritmo de hash y comprueba si tiene alguna consulta idéntica almacenada, en caso afirmativo devolverá el resultado cacheado. La caché de consultas es muy útil en tablas que no cambian frecuentemente y donde se realizan muchas peticiones idénticas, suele ser el caso de páginas web dinámicas que muestran el resultado almacenado en base de datos. Se activa con la directiva query_cache_type en el fiche my.cnf (OFF o 0 desactiva la caché, ON o 1 activa excepto cuando se usa SQL_NO_CACHE y 2 solo guarda resultados en caché cuando se indica expresamente con SQL_CACHE).
2.- Parseado: Si la consulta no se encuentra en caché se parsea, comprobando la sintaxis de la consulta y dividiéndola en sus elementos básicos. Se identifica el tipo de consulta, las tablas que están involucradas y se gestiona la cláusula WHERE para su ejecución.
3.- Planificación: Una identificados todos los elementos que intervendrán en la consulta llega el momento de decidir como será ejecutada. Con EXPLAIN podemos ver el plan que seguirá MySQL para resolver una consulta, lo que nos ayudará a modificar las intenciones de resolución escogiendo la que más nos convenga.
4.- Ejecución: Con todo decidido resta ejecutar la consulta y devolver el resultado.

Y hasta aquí todo el misterio que encierra la ejecución de una consulta sobre MySQL. El modo en el que ayudamos a que MySQL resuelva eficazmente las consultas realizadas determina en la mayoría de los casos el resultado final de rendimiento de una base de datos.

Habitualmente la mayor parte de las bases de datos están mal aprovechas, bien porque han crecido más de lo planteado o por un mal diseño del almacenamiento. Muchas veces se suele intentar solucionar a golpe de mejora de hardware, cuando en realidad una buena optimización ayudando a MySQL a ejecutar los procesos de consulta suele repercutir en una mejora mucho mayor que ofrecerle un hardware más potente.

• Como primera recomendación al hacer una consulta a una tabla es no usar “*” en el SELECT. ¿Si no se van a usar todos y cada uno de los campos definidos en esa tabla que sentido tiene que usemos toda la información? Ninguno, pues eso, definir la consulta con SELECT campo1, campo2, … FROM dará mejor resultado
• Probar la consulta que vamos a implementar con EXPLAIN y analizar el resultado. Intentaremos que las consultas que realicemos no contengan ALL en la columna type, puesto que en ese caso se hará un escaneo completo de la tabla.
• Los campos utilizados con la cláusula WHERE son buenos candidatos a ser índices, comprueba con EXPLAIN como los usaría MySQL para determinar si está aconsejado su uso.
• Evitar el uso innecesario de LIKE y RLIKE, pues realizar comparaciones extensas llevará mucho más tiempo. Si se usan tablas MyISAM pueden utilizarse índices FULLTEXT sobre los campos de texto donde se realice la comparación.
• Al insertar registros, resulta más eficiente la escritura de varias sentencias la mismo tiempo que varias por sepado. Con INSERT DELAYED puedes generar una cola que esperará hasta que la tabla no esté siendo utlizada (No puede usarse con todos los motores). Utilizando INSERT LOW_PRIORITY darás prioridad a las sentencias de escritura y con SELECT HIGH_PRIORITY darás prioridad a las sentencias de consulta.
• Cuando la cantidad de resultados a devolver por MySQL no va a ser utilizada en su conjunto, como cuando se usa un paginador, devolver la cantidad apropiada utilizando la cláusula LIMIT.

Ante todo hay que mantener una premisa básica: no guardar datos innecesarios y no extraer información que no se va a utilizar.

Podríamos centrarnos en tres escenarios a la hora de acometer una optimización de MySQL: la optimización de la base de datos, la mejora de las consultas que se realizan sobre ella y por último, pero no menos importante, el pulido de los programas que trabajan con los datos. Hoy vamos a centrarnos en la primera parte.

Optimizar la base de datos

• El primer punto a tener en cuenta será el diseño de la base de datos en el momento de su creación. No hay mejor remedio que hacer bien las cosas desde un principio. Habrá que pararse a calcular la carga que va a soportar MySQL, tanto a nivel de accesos como la cantidad de datos de habrá que almacenar. También es importante pensar como se extraerán los datos a la hora de hacer las tablas y que relaciones mantendrán esos datos con otras tablas y campos.
• Para el uso de cada tipo de campo sobre nuestras tablas debemos buscar siempre los más adecuados al tipo de dato que tendremos que almacenar. Un campo incorrecto forzará a trabajar más de lo necesario a nuestro motor de base de datos. Debemos evitar el uso de campos de longitud variable si no los necesitamos, intentaremos usar campos numéricos en lugar de campos de texto y evitaremos que los campos puedan contener NULL (ralentizará las consultas innecesariamente).
• Una vez tenemos el modelo de nuestra base de datos, debemos pensar en como se consultarán los datos para generar los índices. Cuando mejores sean los indices que tengamos, con mayor rapidez realizará MySQL las consultas solicitadas. Para ello podemos hacer uso de EXPLAIN para que nos muestre como se harán las consultas y que índices utilizará MySQL. Como orientación será bueno tener índices sobre aquellos campos que sean utilizados en las clausulas WHERE o JOIN, y no crees índices innecesarios, se actualizarán con cada modificación haciendo un trabajo innecesario.
• Otro punto importante y en el que la mayoría no se fijan, piensa si no será mejor que la base de datos viva por su cuenta y que las aplicaciones accedan a los datos a través de procedimientos almacenados y funciones. De este modo será posible realizar modificaciones no previstas sin tener que tocar nada en las aplicaciones que acceden a los datos.
• Hasta aquí sobre la creación y diseño, ahora viene el apartado de mantenimiento de los datos. Primer consejo y el más importante: mantener la base de datos con la información necesaria. Para ello cada cierto tiempo hay que realizar limpieza y eliminar o archivar aquellos datos que ya no sean necesarios. Por otra parte, cuando se han realizado muchos cambios debemos volver a reorganizar la información, para ello ejecutamos OPTIMIZE TABLE, que se encargará de reparar y optimizar los datos e índices de las tablas.
• Puede que en determinado momento se produzca una inserción masiva de datos por alguna circunstancia imprevista. Llegados a este punto, lo mejor es volver a analizar si el diseño de la base de datos se sigue correspondiendo con el objetivo definido durante su diseño inicial. Suele ser una de las cosas que más pereza da realizar, sobre todo porque tendrá incidencia sobre las aplicaciones que ya utilizan la base de datos, pero que mejor resultado puede dar cuando hablamos de optimización. En este apartado es cuando vienen muy bien tener procedimientos almacenados y funciones.

Mejorar las consultas a la base de datos

Esta nueva versión de HeidiSQL [descarga] es el resultado de 331 cambios realizados sobre la versión 5.1 y que incluye algunas nuevas funcionalidades como:

• Resultados por lotes en una misma ficha de consulta
• Múltiples conexiones en una sola instancia de la aplicación
• Resultados de la consulta editables
• Administración de usuarios utilizando la sintaxis GRANT y REVOKE
• Ejecución de la consulta actual con [Mayús + Ctrl + F9]
• Vista previa de imágenes incluidas en campos BLOB

HeidiSQL es una buena alternativa a MySQL Workbench para la gestión de bases de datos, además incluye una versión “portable” para poder llevarlo siempre cargado en un USB y tenerlo disponible en cualquier momento, nunca se sabe cuando se va a necesitar acceder a una base de datos.

Para poder ejecutar procedimientos almacenados es necesario tener la tabla proc en la base de datos mysql y contar con los permisos necesarios para trabajar con ellos. Estos son los permisos relacionados con los procedimientos:

• CREATE ROUTINE: Permite crear procedimientos almacenados
• ALTER ROUTINE: Da acceso a la modificación y borrado, se aplica por defecto al creador de un procedimiento.
• EXECUTE: Requerido para poder ejecutar procedimientos almacenados, se otorga automáticamente al creador del procedimiento. Por defecto, quien tiene acceso a la base de datos también lo tiene para ejecutar los prodecimientos almacenados para esa base de datos.

Vamos a ver un ejemplo de como trabajar con procedimientos almacenados con un sencillo ejemplo. Para crearlo usaremos:

CREATE PROCEDURE sumar (IN valor INTEGER, OUT resultado INTEGER)
SELECT valor+valor INTO resultado;

Lo que estamos indicando es que se cree el procedimiento “sumar” con dos parámetros “valor” y “resultado”, ambos del tipo INTEGER. El primero es un parametro de entrada y el segundo la variable donde almacenaremos el valor de salida. Ahora vamos a llamarlo usando:

CALL sumar(4, @resultado);

El procedimiento se encargara de hacer la suma de 4+4 y almacenar la salida en la variable @resultado. Para visualizar lo que contiene la variable:

SELECT @resultado;

Los procedimientos son una buena forma de trabajar con los datos almacenados en una base de datos, dejando a MySQL el trabajo de formatear y filtrar el manejo de los datos, por lo que la cantidad de información que ha de viajar entre la base de datos y nuestro programa se reduce considerablemente. Por otra parte usando dos servidores, uno para el programa y otro para la base de datos, podríamos trasladar parte de la carga de procesamiento a la base de datos.

A la hora de realizar una buena optimización de las consultas de MySQL habrá que prestar mucha atención a lo que dice la cláusula EXPLAIN. Su sintaxis es muy sencilla, basta anteponerlo a la consulta que queremos realizar para obtener toda la información.

EXPLAIN SELECT columna1, columna2 FROM tabla1 WHERE columna3 = ‘2′\G

El resultado que obtendremos será el plan de ejecución de la consulta a la base de datos. Una explicación de como accederá MySQL a las diferentes columnas involucradas en la consulta. EXPLAIN devolverá:

• id: Es el identificador que EXPLAIN asignará a la consulta.
• select_type: Tipo de consulta a analizar. Por ejemplo, si se trata de una consulta sencilla su valor será SIMPLE.
• table: Nombre de la tabla a la que hacen referencia el resto de datos en la fila. Hay que tener en cuenta que el orden de las filas será el que utilizará MySQL para acceder a los datos.
• type: Indica como MySQL combinará los datos de esa tabla.
• possible_keys: Lista de los indices que se podrían utilizar, aunque podría no usarse ninguno.
• key: Índice que finalmente se usará, si no se usa ninguno el valor del campo será NULL.
• key_len: Tamaño del indice utilizado, si no se usó ninguno contendrá NULL.
• ref: Muestra con que campo está relacionado el índice seleccionado.
• rows: Número de registros que se tendrán que recuperar para ejecutar la consulta.
• extra: Información adicional sobre la forma en que se obtendrán los datos.

Con esta información es posible encontrar donde se producen los cuellos de botella en las consultas que realizamos a la base de datos, y nos permitirá optimizarlas para evitar que una consulta lenta provoque un retraso injustificado en la devolución de resultados a los usuarios. En el manual de MySQL puedes encontrar más información.

El servidor Esclavo mantiene una conexión permanentemente abierta con el Maestro y se comprueba la ultima posición escrita en el log binario del Maestro, cuando se detectan cambios estos se replican el las tablas del servidor Esclavo.

Antes de ponerse a configurar MySQL con una replicación, hay que tener en cuenta la compatibilidad entre versiones. Como norma general debería de intentarse que la versión de MySQL del Maestro y del Esclavo fuesen la misma, y lo más actualizada posible. De todos modos, un Esclavo con una versión más actualizada que el Maestro suele funcionar, pero no al contrario.

Una vez que conocemos como funciona, y realizadas las comprobaciones de versiones podemos configurar Maestro y Esclavo para que ejecuten la replicación. Comenzaremos por la configuración del Maestro. Debemos editar el fichero my.cnf que encontraremos normalmente en /etc/my.cnf o en /etc/mysql/my.cnf dependiendo del sistema que usemos.

Debemos buscar y editar, o crear en caso de que no existan, dentro de la sección [mysql] las siguientes líneas:

[mysql]
log-bin = mysql-bin
server-id = 1
binlog_do_db = base_de_datos_a_replicar, db2, db3
binlog_ignore_db = bases_de_datos_a_ignorar, db4, db5

La opción log-bin activa el log binario de mysql, y server-id sirve para indicar el id del servidor maestro, debe ser un número entero positivo entre 1 y 2³². Con binlog_do_db le indicamos las bases de datos que queremos copiar (separadas por comas) y con binlog_ignore_db aquellas que no queremos replicar. Una vez realizados los cambios debemos reiniciar el servidor mysql.

Ahora necesitamos crear un usuario en el Maestro (se recomienda que se use un usuario de MySQL exclusivamente para hacer la replicación) y asignarle los permisos de replicación con el siguiente comando:

mysql> GRANT REPLICATION SLAVE ON *.*
-> TO ‘usuario_replicacion’@'%’
-> IDENTIFIED BY ‘pass_usuario’;
mysql> FLUSH PRIVILEGES;
mysql> LOCK ALL TABLES READ ONLY;

Debemos sustituir usuario_replicacion por el nombre de usuario que hemos creado para hacer la repicación y pass_usuario por la contraseña de ese usuario. El valor ‘%’ indica que ese usuario puede acceder desde cualquier host remoto, si queremos indicarle que pueda acceder desde un determinado nombre de dominio o IP debemos cambiar % por la IP o nombre de dominio que queramos que acceda a la replicación.

En el fichero de configuración del Esclavo debemos indicarle un server-id distinto del servidor Maestro, también un número entero positivo entre 1 y 2³². Por ejemplo:

[mysql]
server-id = 2

Si se están configurando varios esclavos cada uno de ellos debe de tener un server-id único, y diferentes del server-id del maestro. Una vez guardados los cambios reinicia el servidor MySQL.

Ahora ya tenemos listos Maestro y Esclavo para realizar la conexión. Ahora debemos hacer un volcado de la base de datos del servidor Maestro que queremos replicar:

[root@servidor-maestro]:~$ mysqldump -u usuario -p nombre_db > nombre_db.sql

Con este comando haremos un volcado de la base de datos a un fichero. Debemos sustituir nombre_db por el nombre de la base de datos que vamos a replicar y usuario por el nombre del usuario con privilegios de administracion. Si no tenemos contraseña para ese usuario no incluiremos la opción -p, en caso contrario nos pedirá la contraseña antes de realizar el volcado.

Ya solo nos queda un paso en el Maestro, conocer el nombre del log binario que se está utiliando y la posición del mismo, accedemos a la línea de comandos de MySQL y ejecutamos:

mysql> SHOW MASTER STATUS;
+——————-+———-+——————-+————————+
| File                         | Position | Binlog_Do_DB | Binlog_Ignore_DB  |
+——————-+———-+——————-+————————+
| mysql-bin.0005 |           98  |                                 |                                        |
+——————-+———-+——————-+————————+

Guardamos esos datos y desbloqueamos las tablas del maestro con:

mysql> UNLOCK ALL TABLES;

Ahora volvemos al esclavo y cargamos el volvado de la base de datos del maestro que realizamos antes:

[root@servidor-esclavo]:~$ mysql -u usuario -p nombre_db < nombre_db.sql

Cuando se temine la carga de la base de datos, accedemos a la línea de comandos de MySQL del esclado para indicarle los datos del maestro e iniciar el esclavo:

mysql> CHAGE MASTER TO MASTER_HOST = ‘ip_del_servidor_maestro’;
mysql> CHAGE MASTER TO MASTER_USER = ‘usuario_replicacion’;
mysql> CHAGE MASTER TO MASTER_PASSWORD = ‘pass_usuario’;
mysql> CHAGE MASTER TO MASTER_LOG_FILE = ‘mysql-bin.0005′;
mysql> CHAGE MASTER TO MASTER_LOG_POS = 98;
mysql> START SLAVE;

Después de esto el servidor Esclavo iniciará la replicación copiando todo lo sucedido desde la posición del log binario indicada hasta ese instante. Para confirmar que todo es correcto podemos ejecutar el siguiente comando en la consola de MySQL:

mysql> SHOW SLAVE STATUS \G
****************** 1. Row ***********************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.54
Master_User: usuario_replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.0005
Read_Master_Log_Pos: 98
Relay_Log_File: esclavo-rely-bin.0001
Relay_Log_Pos: 105
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Aunque apareceran más cosas, las he omitido, lo que debeis tener en cuenta es Seconds_Behind_Master pues indica el tiempo en segundos que el Esclavo tiene con respecto al Maestro. Creo que no me queda nada, teneis más información en el manual de MySQL, y si teneis alguna duda dejadla en los comentarios.

Asterisk es una centralita telefónica bajo software libre. Nos permite tener un sistema de telefonía IP bajo diferentes protocolos y con distintos proveedores. Todo esto nos da la posibilidad de ofrecer llamadas a otros usuarios, lo cual en algunos casos puede significar crear un negocio con esto.

Y como en cualquier negocio lo importante es poder facturar, en este caso en función del destino de la llamada, el horario o el tipo de servicio utilizado. Para lograrlo A2Billing provee un software a través de entorno web que nos permite definir precios, tramos horarios, etc. Esta herramienta está desarrollada bajo PHP y MySQL.