Mysql - Procedimiento "Create Database" sin ser admin.

Hace unos días se me planteo la necesidad de que usuarios no administradores pudiesen crear bbdd's en un server mysql y que además ganasen privilegios sobre las mismas.

Lo que se nos ocurrió fue lo siguiente, quizás(seguro) no sea la mejor solución pero funciona bien. Así que ahí la dejo... por si le sirve a alguien.

Para poder crear bbdd con usuarios no administradores se ha creado un "Procedimiento almacenado " en una bbdd creada específicamente para almacenar este u otros procedures.
En este caso la he llamado "gestion".

1.- Con usuario "root" creamos la bbdd donde almacenaremos el procedure.

mysql>create database gestion;

2.- Dentro de esta bbdd cargamos el procedure

mysql>use gestion;

(En la consola pegamos el procedure del final de la nota. Negrita)

     mysql> DELIMITER //
     mysql> CREATE PROCEDURE CreateAppDB(
         ->     IN db_name VARCHAR(50))
         -> BEGIN
         ->     DECLARE myvar VARCHAR(32);
         ->
         ->     -- Create database
         ->

(En la creación de la bbdd añadimos un prefijo "ext_" para tener controladas las bbdd que creen los usuarios.)
         ->     SET @s = CONCAT('CREATE DATABASE ext_', db_name);
         ->     PREPARE stmt FROM @s;
         ->     EXECUTE stmt;
         ->     DEALLOCATE PREPARE stmt;
         ->
         ->     -- Grant permissions

(Aqui obtenemos el usuario que esta lanzando el procedure sin la parte "@XXX" que completaremos con @%, esto se almacena en "myvar")         ->     SELECT LEFT(USER(), LOCATE('@',USER()) - 1) INTO myvar;
         ->     SELECT myvar;
         ->
         ->     SET @s = CONCAT('GRANT ALL ON ext_', db_name, '.* TO ', myvar, '@''%''');
         ->     PREPARE stmt FROM @s;
         ->     EXECUTE stmt;
         ->     DEALLOCATE PREPARE stmt;
         -> END//
     Query OK, 0 rows affected (0.00 sec)

     mysql> DELIMITER ;
     mysql>

3.- Al usuario que se le quiera dar la posibilidad de crear bbdd se le dará permisos de ejecución sobre la bbdd gestión y sobre el procedure.

(Nota. Si el usuario no conecta desde localhost las definiciones de usuario siguientes cambian)

mysql> grant execute on procedure gestion.CreateAppDB to 'USER'@'localhost' identified by 'XXXXXX';
Query OK, 0 rows affected (0.01 sec)

----

mysql> grant execute on gestion.* to 'USER'@'localhost' identified by 'XXXXXX';

Query OK, 0 rows affected (0.00 sec)

4.- Conectamos con este usuario y lanzamos el procedimiento.

#mysql -u USER -p gestion

mysql>call gestion.CreateAppDB('nombre_bbdd'); 

5.- Tenemos creada una bbdd "ext_nomreb_bbdd" con permisos para el usuario "USER@%"

DROP PROCEDURE IF EXISTS CreateAppDB;
DELIMITER //
CREATE PROCEDURE CreateAppDB(
    IN db_name VARCHAR(50))
BEGIN
    DECLARE myvar VARCHAR(32);

    -- Create database

    SET @s = CONCAT('CREATE DATABASE ext_', db_name);
    PREPARE stmt FROM @s;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;

    -- Grant permissions
    SELECT LEFT(USER(), LOCATE('@',USER()) - 1) INTO myvar;
    SELECT myvar;
   
    SET @s = CONCAT('GRANT ALL ON ext_', db_name, '.* TO ', myvar, '@''%''');
    PREPARE stmt FROM @s;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END//
DELIMITER ;

La idea original sale de este post, sobre el cual se han hecho pequeñas modificaciones.

Aquí

Optimización MySql

Hace ya bastante tiempo comente acerca de un problema de rendimiento con MySql y las SlowQuerys
Bueno pues como la historia siempre se repite (o eso dicen), ha vuelto a ocurrir, pero esta vez hasta que se ha descubierto, que el problema era el mismo, se han probado y profundizado en aspectos que mejoran el rendimiento de MySql
Esto es lo que voy a comentar brevemente.

1.- Lo primero ha sido garantizar que este error no se produce otra vez y para eso he creado un mini script que me vacíe la tabla en cuestión, citada en el post anterior.


NUM_ROWS=`mysql -u root -pXXXXX NOMBRE_BBDD -e"SELECT COUNT(*) FROM NOMBRE_TABLA;"`
#Quitamos 9 caracteres "COUNT(*) " que aparecen en la salida de mysql
NUM_ROWS=`echo${NUM_ROWS:8}`

if [ $NUM_ROWS -gt 2500000 ]; then
echo `date`
echo "El tamano es excesivo, $NUM_ROWS de entradas, hay que vaciar la tabla
NOMBRE_TABLA"
RESULT=`mysql -u root -pXXXXX NOMBRE_BBDD -e"TRUNCATE TABLE NOMBRE_TABLA;"`
echo $RESULT
fi


2.- Thread_cache_size y Thread_cache_concurrency

Esta es la primera parte de la "optimización" que se ha realizado.
Parece que Linux no gestiona bien la creacion de threads, por lo que crear nuevos supone un coste muy elevado.

Cuando tenemos muchas conexiones nuevas a BBDD, es necesario crear estos threads, mientras que si almacenamos los que van quedando libres al desconectarse un usuario, la reasignación de estos es mucho menos costosa, con lo que mejoramos el rendimiento.

Para decidir el valor optimo, podemos empezar por el recomendado "8", he ir ajustándolo de la siguiente manera.


mysql> show status like '%Thread%'; .... | Threads_created | 214 | ....


mysql> show status like '%Conn%'; ... | Connections | 14250 | ...


Threads_created/connections

Si este valor se aproxima a "1", significa que creamos tantos threads como conexiones tenemos, por lo que habria que aumentar el tamaño de la cache de threads.

Si este valor se aprixima a "0" significa que apenas creamos threads nuevos con lo que el tamaño de cache es correcto.



3.-Key_buffer_size


Esta variable indica el tamaño del buffer donde se almacenaran los indices de las tablas MyIsam.
A mas indices cacheados mas accesos en las consultas se servirán desde RAM y menos desde disco, con al aumento de rendimiento que esto supone.

Aquí ya que aún no lo hemos ajustado no voy a profundizar mucho más simplemente comentar que.


key_read_request (indices servidos desde RAM)
key_reads (indices servidos desde disco)


Con estas dos variables podemos ver lo siguiente.


key_read_request 10000
key_reads = 100


key_read_request/key_reads=100


Por lo que estamos obteniendo una proporción de 100 a 1, es decir por cada 100 indices servidos desde RAM 1 es servido desde disco.


Esta es la relación mínima que se cita en la documentación que he encontrado aunque también hablan de valores de 1000 a 1, por lo que cuanto más alto mejor.


Bueno con los ajustes necesarios de estas variables deberíamos notar una mejora de rendimiento en nuestros servidores.

Pérdidas de rendimiento Mysql - SlowQueries

Hace unos días, tuvimos en el trabajo un problema con una aplicación que consulta a BBDD MySql, ya que esta dejaba de responder sin más.

En los momentos en los que esto sucedía, se podía observar el siguiente comportamiento:

-No había errores en los logs de Apache ni en los de MySql.
-El consumo de memoria de Apache no era desorbitado, aunque si alto.
-MySql seguia respondiendo correctamente, pero el servidor Apache de la aplicación parecía estar muerto...
-El número de conexiones a BBBDD era normal.
-El número de conexiones en el servidor web era normal.

Bueno para resumir todo el proceso, la cuestión empezó a clarificarse en el momento que se activaron los logs para SlowQueries de MySql ;)

En el fichero de configuracion de mysql /etc/my.cnf añadimos

[mysqld]
log-slow-queries=/mysql/var/log/mysql-slow.log

Tras un día de logs, se podía observar lo siguiente:

[root@xxxxxx~]# mysqladmin version -u root -p ........... Threads: XXX Questions: XXX Slow queries: 6 Opens: XXX Flush tables: X Open tables: XXX Queries per second avg: XXX

Revisando los logs generados

[root@xxxxxx~]# cat /mysql/var/log/mysqlslow.log

se puede ver a que tabla accede la query cuando genera la entrada de log.

Por último usando la aplicación "MySql Administrator 1.2.14", se vio que el tamaño de una tabla de índices, usada para cachear las búsquedas de la aplicación, era desorbitadamente grande.

Claro está el problema se solucionó vaciando esta tabla, para que fueran recacheados los resultados.

Este mismo problema está tratado con anterioridad aquí

Administracion básica MySql

Cada vez mas tengo la necesidad de documentar todo lo que me ocurre en la administración de MySql, para consultas posteriores.
Así que he ido recopilando de aquí y alla, todo lo que voy necesitando, y lo he agrupado en un documento vital para mi.
El documento está en continua evolución ya que se añaden puntos nuevos segun me surgen, pero no voy a ir actualizando el articulo cada vez ;)
Bueno como punto de inicio creo que puede ser util.

Las fuentes principales, estan al final del documento.



Estructura y Funcionamiento del servidor MySQL

-Desde el punto de vista del cliente:

El cliente se conecta al servidor, iniciando la autenticación, codifican, comprimen, cifran y envían las peticiones.
El servidor resuelve la petición y envía la respuesta que es cacheada por el cliente.

-Desde el punto de vista del servidor:

Existen dos capas en el servidor, con tareas independientes. Capa de Manipulación y Motores de almacenamiento.

Capa de manipulación:

Se encarga de desencriptar, validar la sintaxis y buscar en la cache, las peticiones de los clientes, así como de escribir logs y
actualizar la cache. Si no encuentra un resultado valido, envía esta petición al motor de almacenamiento correspondiente.

Motores de Almacenamiento (MyISAM, InnoDB….):

Obtiene los resultados de Memoria o Disco.


Como almacena la información MySQL

Almacenamiento en Disco

Los tipos de información que guarda MySQL en disco son:
1.-Bases de Datos
*.frm (Formato de tabla)-> Para todos los motores de almacenamiento
*.MYD (Fichero de datos) -> Para algunos motores de almacenamiento.
*.MYI (Ficheros de índices) -> Para algunos motores de almacenamiento.
2.-Programas de cliente y servidor así como sus librerías.
3.-Logs
4.-Tablespaces para InnoDB, si los hay
5.-Tablas temporales que hayan sobrepasado el tamaño máximo permitido en memoria


Almacenamiento en Memoria

Los tipos de información que guarda MySQL en memoria son:
1.-Copia de la tabla de permisos
2.-Caches de hosts, tablas y consultas
3.- Tablas temporales que NO hayan sobrepasado el tamaño máximo permitido en memoria
4.-Gestor de conexiones (Cada conexión establecida)


Limitaciones del sistema operativo.

Las limitaciones más significativas del sistema vienen dadas por:

1.-Numero máx. de ficheros abiertos.

Limite de Mysql:
su -m mysql
ulimit –a

Limite de SO:
[root@nodo]# sysctl -a|grep file
fs.file-max=206210

2.-Numero máx.. de hilos por proceso.
3.-Backlog del sistema, el cual indica el número máx. de clientes que pueden estar esperando una conexión.
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
4.-Sistema de ficheros, el cual limita el tamaño máx. de los mismos.


Tipo de motores de almacenamiento.

Breve descripción de las características de algunos motores de almacenamiento.

MyISAM
-No transaccional
-Bloqueo a nivel de tablas
-Los datos son almacenos en disco. Un fichero para la definición de tabla, uno para los índices y otro para los datos. (Esquema)
-Muy rápido en lectura y escritura, si no hay escrituras simultaneas.
-Para la recuperación de errores, necesita lanzar un proceso y recorrer las tablas.
-Consume poco espacio en disco y en memoria.
-Buena elección si necesitas velocidad y existen pocas modificaciones simultaneas.

InnoDB
-Transaccional
-Bloqueo a nivel de filas
-Restricciones de claves foráneas
-Los datos son almacenados en disco. Un fichero para la definición de las tablas y un tablaspace para datos e índices.
-Capaz de recuperarse de errores con los ficheros de log
-Consume mucho espacio en disco y en memoria.
-buena elección si necesitas transacciones, claves foráneas o si hay muchas modificaciones simultaneas.



Administración de usuarios.

Los usuarios en MySQL, quedan identificados por la tupla [usuario/host], por lo que el usuario X y el usuario X@localhost
pueden tener permisos diferentes, ya que para el servidor son usuarios distintos.
El carácter comodín es el “%”
Ejemplos:
celtha@’localhost’
celtha@’192.168.1.156’
celtha@’%’
%@’127.0.0.1’
celtha@’192.168.1.%’


Los usuarios son almacenados en la BBDD “mysql” en la tabla “user”


Listar usuarios

mysql> SELECT User,Host,Password FROM mysql.user;

Crear usuarios

mysql> create user anonimo@localhost;
o
mysql> create user anonimo@localhost IDENTIFIED BY 'password';

Eliminar usuarios

mysql> drop user anonimo@localhost

Renombrar usuarios

mysql> rename user anonimo@localhost to anonimo;

Cambiar y/o poner password de usuario

mysql> set password for anonimo@'%' = PASSWORD('1234');

Privilegios de usuarios

Cada usuario tiene unos privilegios específicos sobre una o varias BBDD.
Los privilegios son almacenados en la BBDD “mysql”, en las tablas ('user', 'db', 'tables-priv', 'columns_priv' y 'host')

Ver privilegios de un usuario

mysql> show grants for root;

Asignar privilegios

Nota: Si el usuario objetivo no existe será creado en la misma operación.
Sintaxis:
grant privilegios ON base_datos.tabla(columnas) TO usuario

Tipos de privilegios:
ALL, ALTER, CREATE, CREATE USER, CREATE VIEW, DELETE, DROP, EXECUTE, INDEX, INSERT, LOCK TABLES, RELOAD,
SELECT, SUPER, UPDATE, GRANT OPTION, ...


mysql> grant all on *.* to operador@'%' identified by '1234';

Eliminar privilegios

mysql> REVOKE ALL ON *.* FROM operador@'%';

Recuperar password

Podemos iniciar el servidor haciendo que este no tenga en cuenta los privilegios de los usuarios.

mysqld --skip-grant-tables --skip-networking

Lanzamos el cliente, haciendo que ejecute un update del usuario root.

mysql -e "UPDATE mysql.user SET Password = PASSWORD('nuevo') WHERE User = 'root'"



Conexiones al servidor

Listar conexiones

mysql> show full processlist;
o
mysql> show processlist;


Matar conexiones

Kill ID

mysql> kill 5;


Ejemplos de Consultas.

SELECT

SELECT City.Name, Country.Name FROM City, Country
WHERE City.CountryCode=Country.Code ORDER BY Country.Name;

DELETE

DELETE FROM City WHERE CountryCode='ESP' AND Population>500000;

INSERT

INSERT INTO City (Name, CountryCode, District, Population)
VALUES ('JoanBrossa','ESP', 'Katalonia', 3500000);
INSERT INTO City SET Name='JoanBrossa', CountryCode='ESP',
District='Katalonia', Population=3500000;


UPDATE

UPDATE City SET Population=5000000 WHERE Name='JoanBrossa';
UPDATE City SET Population=5000000 WHERE Population>1000000;


NOTAS

FROM:
Especifica la tabla de la cual se seleccionan los registros

WHERE:
Detalla las condiciones que han de reunir los registros resultantes

GROUP BY:
Separa los registros seleccionados en grupos específicos

HAVING:
Expresa la condición que debe cumplir cada grupo

ORDER BY:
Ordena los registros seleccionados de acuerdo a una ordenación específica

LIMIT:
Restringe el número de resultados devueltos.



Administración de Tablas

Crear una BBDD:
CREATE DATABASE nombre_BBDD;

Borrar toda una BBDD:
DROP DATABASE nombre_BBDD;

Ver las BBDD del sistema:
SHOW DATABASES;

Seleccionar una BBDD para ser usada:
USE nombre_BBDD;

Crear una tabla:
CREATE TABLE nombre_tabla definición;

Borrar toda una tabla:
DROP TABLE nombre_tabla;

Cambiar la definición de una tabla:
ALTER TABLE tabla modificación;

Ver las tablas de una base de datos:
SHOW TABLES;

Ver la descripción de los campos de una tabla:
DESCRIBE nombre_tabla;

Bloquea una tabla y sólo deja leer:
LOCK TABLES nombre_tabla READ;

Bloquea una tabla y sólo deja leer y escribir a quien la bloqueo:
LOCK TABLES nombre_tabla WRITE;

Desbloquea las tablas:
UNLOCK TABLES;

Ejecuta un fichero de sentencias SQL:
SOURCE fichero_SQL;


Copias de Seguridad.

Las BBDD están almacenadas en el directorio de trabajo de MySQL, por defecto “/var/lib/mysql”, para verificarlo, desde MySQL se puede ejecutar:

mysql> show variables like 'datadir';

Existen muchos métodos para realizar esta tarea, aquí se muestran solo algunos.

COPIAS EN FRIO
1.- Paramos el servidor:
/etc/init.d/mysqld stop

2.- Copiamos o Restauramos los ficheros de BBDD que tienen nuestros datos.
MyISAM
*.frm
*.MYI
*.MYD
InnoDB
*.frm
ibdataX
ib_logfileX
3.- Arrancamos el servidor.
/etc/init.d/mysqld start


COPIAS EN CALIENTE

Utilidad “mysqldump”, estas copias son portables, a otros gestores de BBDD, ya que crean un fichero .
de texto , con las sentencias sql para crear la BBDD y hacer los “INSERTS” necesarios.

Copiar Datos.

#mysqldump --add-locks --add-drop-table -u usuario --password=password "nombre_BBDD" > /tmp/copia.sql

Restaurar Datos.

#mysql –u usuario –p BBDD < /tmp/copia.sql


COPIAS Herr. GRAFICA

Existe una herramienta grafica “MySQL Administrator”, la cual nos permite programar tareas para las copias de seguridad.

Checkeo y Reparación de Tablas.

En el proceso de reparación se suelen perder los registros defectuosos.

CHECK TABLE Nombre_tabla EXTENDED;
REPAIR TABLE Nombre_tabla;

Para este propósito se suelen usar aplicaciones externas. Uno ejemplos son los siguientes.


MYISAMCHK

Esta aplicación accede directamente a los ficheros de datos por lo que necesita que este parado el servidor de mysql.

Solo para MyISAM

/etc/init.d/mysql stop
myisamchk --check /var/lib/mysql/*/*.MYI
myisamchk --recover /var/lib/mysql/BBDD/*.MYI
myisamchk --safe-recover /var/lib/mysql/BBDD/Tabla.MYI
myisamchk --key_buffer_size=64M --sort_buffer_size=64M
--read_buffer_size=1M --write_buffer_size=1M
--silent --force --fast --update-state /var/lib/mysql/BBDD/*.MYI

/etc/init.d/mysql start


MYSQLCHECK

Esta aplicación, ejecuta sentencias sql por lo que necesita que el servidor esté en ejecución. Para tablas MyISAM, InnoDB, BDB.

mysqlcheck -u root -p --check BBDD Tabla
mysqlcheck -u root -p --repair BBDD Tabla
mysqlcheck -u root -p --force BBDD Tabla

También se puede realizar fácilmente las tareas de reparación con PhpMyAdmin (Entorno Web).


Ficheros y Directorios importantes.

/var/lib/mysql
Guarda las bases de datos del servidor. Los archivos y directorios contenidos aquí son propiedad de MySQL.

/var/log/mysql/
Anotaciones y alertas del servidor.

/etc/mysql/
Ficheros de configuración general (my.cnf). Cada vez que cambiemos la configuración deberemos reiniciar el servidor para que se activen los nuevos cambios.

/etc/init.d/mysql
Script para arrancar, parar y reiniciar el servidor

/usr/bin/ , /usr/sbin/ , /usr/share/mysql/
Programas de MySQL


Arranque y Parada del servidor

Se puede iniciar la ejecución de varias maneras:

/etc/init.d/mysql start
/usr/sbin/mysql start
/usr/bin/mysqld-multi
/usr/bin/mysqld-safe

Se puede parar la ejecución de varias maneras:

/etc/init.d/mysql stop
/usr/sbin/mysql stop
mysqladmin -u root -p shutdown

NOTA: El puerto por defecto del servidor MySQL es el TCP/UDP 3306.

Si quiero acceder remotamente al servidor debo modificar
/etc/mysql/my.cnf

Comentar la línea "bind-address" o comentar la línea "skip-networking"

Si quiero los mensajes en otro idioma debo modificar /etc/mysql/my.cnf y cambiar
[mysqld]
language =

Por ejemplo

"laguage = spanish"


Cache de Querys

Esta explicado en un articulo anterior.


Logs de consultas pesadas.

Una buena practica ante situaciones donde el rendimiento de MySQL no es el que se espera, es comprobar si existen consultas demasiado pesadas.Estas pueden ser logeadas, para su posterior análisis.


Cuantas Slow Querys

[celtha@legolas ~]$ mysqladmin version -u root -p
Enter password:
mysqladmin Ver 8.41 Distrib 5.0.45, for redhat-linux-gnu on i686
Copyright (C) 2000-2006 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version 5.0.45
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 1 hour 24 min 11 sec

Threads: 1 Questions: 5 Slow queries: 0 Opens: 12 Flush tables: 1 Open tables: 6 Queries per second avg: 0.001
[celtha@legolas ~]$

Este valor se puede configurar en “my.conf”

Se crea el fichero y se le dan los permisos pertinentes.

[mysqld]
log-slow-queries=/var/log/mysql/log-slow-queries.log



Para profundizar.

Referencia oficial.
http://dev.mysql.com/doc/refman/5.0

Excelente documento en castellano.
http://www.xtec.net/~acastan/textos/Administracion%20de%20MySQL.html

Rendimiento en Mysql - Query Cache

Bueno, pues a base de "palos" y gracias a un proyecto del trabajo.... descubrí a ese gran amigo que es el "query-cache" de MySql...

Tras la implementación, he obtenido, mas menos... una ganancia de 3seg. por consulta, lo que en un sitio de mucha carga es una pasada. Además de esto estoy ahora mismo en un ratio "Hits/Inserts" de 2.7 lo cual me parece mas que aceptable de momento. Y lo mejor .... todo esto a costa de 16Mb de Ram, barato no ;)

Pequeño resumen de Query-Cache:
El Query-Cache, como su nombre indica es una cache para consultas de Mysql, no nos olvidemos que cualquier web almacenada en BD, sus paginas son consultas también.
Cuando se realiza una consulta en MySql, si no esta "cacheada", esta se inserta en la cache y se sirve el resultado. La siguiente vez que se realiza esta consulta, se sirve el resultado directamente de la cache. Coste teórico = 0.
Cuando una tabla o registro (segun si tenemos mysam, innodb....) se modifica en disco, los resultados referentes a esta en la cache son descartados.

*Sist. con muchas escrituras, inutilizará las entradas de cache demasiadas veces.

Bueno basta de royo.... la configuración, pruebas y resultados son los siguientes.

/etc/my.conf

.......
######################################
## CONFIGURACION CONEXIONES MAX ##
######################################
table_cache=1000
max_connections=500
######################################
## CONFIGURACION QUERY CACHE ##
######################################
query_cache_type = 1
query_cache_size = 16M
query_cache_limit = 2M
......

Cada parametro es para......
max_connections (Número máximo de conexiones de MySql)
table_cache (Número máximo de descriptores que abrira mysql a la vez. Segun el sistema de BD necesita, un numero de descriptores por conexion. En mi caso Myysam necesita 3, por lo que lo ideal seria 1500, pero ya que uno de ellos se cierra despues de abrirse, considere que 1000 estaba bien.) Si este valor es demasiado bajo on respecto a max_connection, el rendimiento cae en picado, y si es demasiado alto, podemos sobrepasar el limite del SO.o de MySql.

Limite de Mysql:
su -m mysql
ulimit -a
Limite de SO:
[root@nodo]# sysctl -a|grep file
fs.file-max=206210

query_cache_type (Cache ON)
query_cache_size (Tamaño de memoria para la cache, por defecto en RH es 0, por lo que aun estando a 1 el cahe_type, es como si estuviera parada ;)
query_cache_limit (Las consultas cuyos resultados sean mayores a este valor no seran cacheadas)
Ir probando los valores segun las necesidades y las posibilidades..
Una vez configurado esto... rebotamos el servicio y .... woalaaa¡¡

Verificando aciertos:

Desde Mysql..

mysql> show status like '%Qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 1125 |
| Qcache_free_memory | 3122472 |
| Qcache_hits | 32118388 |
| Qcache_inserts | 11866396 |
| Qcache_lowmem_prunes | 11001043 |
| Qcache_not_cached | 542 |
| Qcache_queries_in_cache | 2949 |
| Qcache_total_blocks | 8342 |
+-------------------------+----------+
8 rows in set (0.00 sec)

Ratio Qcache_hits/Qcache_inserts=2.706

Verificando ganancias de tiempos de respuesta:

Antes de configurar nada... Se tomaron las siguientes medidas:

ab -n 30 -c 1 http://sitio_a_probar
"ab-Apache BenchMark"

Con esto se solicita el index.html 30 veces con una concurrencia(peticiones simultaneas) de 1, y se obtienen los tiempos de respuesta.
Tras la configuracion de la cache, se repite la medición y es aquí donde vemos realmente las ganacias obtenidas a costa de 16Mb

Conclusion:
Si la base de datos es principalmente de lectura... "sitio web", la ganancia es muy buena y la configuracion de la cache mas que recomendable.
Si la BD es principalmente de escritura, la ganancia se nota mucho menos, por lo que habría que estudiar el caso concreto.