La sintaxis simplificada de grant consta de tres secciones. No puede omitirse ninguna, y es importante el orden de las mismas:

•    grant lista de privilegios
•    on base de datos.tabla
•    to usuario

Ejemplo

Creación de un nuevo usuario al que se otorga algunos privilegios

En la primera línea se especifican los privilegios que serán otorgados, en este caso se permite actualizar (update), insertar (insert) y consultar (select). La segunda línea especifica que los privilegios se aplican a la tabla precios de la base de datos demo. En la última línea se encuentra el nombre del usuario y el equipo desde el que se va a permitir la conexión.

El comando grant crea la cuenta si no existe y, si existe, agrega los privilegios especificados. Es posible asignar una contraseña a la cuenta al mismo tiempo que se crea y se le otorgan privilegios:

En la misma sentencia es posible también otorgar permisos a más de un usuario y asignarles, o no, contraseña:

MySQL proporciona mecanismos para permitir que el usuario realice su conexión desde diferentes equipos dentro de una red específica, sólo desde un equipo, o únicamente desde el propio servidor.

El carácter % se utiliza de la misma forma que en el comando like: sustituye a cualquier cadena de caracteres. En este caso, se permitiría el acceso del usuario 'visitante' (con contraseña, si la tuviese definida) desde cualquier equipo del dominio 'empresa.com'. Obsérvese que es necesario entrecomillar el nombre del equipo origen con el fin de que sea aceptado por MySQL. Al igual que en like, puede utilizarse el carácter ’_’.

Entonces, para permitir la entrada desde cualquier equipo en Internet, escribiríamos:

Obtendríamos el mismo resultado omitiendo el nombre del equipo origen y escribiendo simplemente el nombre del usuario:

Los anfitriones válidos también se pueden especificar con sus direcciones IP.

Los caracteres ’ %’ y ’_’ no se permiten en los nombres de los usuarios.

Después de analizar las opciones referentes a los lugares de conexión permitidos, veamos ahora cómo podemos limitar los privilegios a bases de datos, tablas y columnas.

En el siguiente ejemplo otorgamos privilegios sobre todas las tablas de la base de datos demo.

Podemos obtener el mismo resultado de esta forma:

De igual modo, al especificar sólo el nombre de una tabla se interpretará quepertenece a la base de datos en uso:

 

Opciones para la clausula on del comando grant

Opción	Significado
*.*	Todas las bases de datos y todas las tablas
base.*	Todas las tablas de la base de datos especificada
tabla	Tabla especificada de la base de datos en uso
*	Todas las tablas de la base de datos en uso

 

A continuación presentamos un ejemplo donde se especifican las columnas sobre las que se otorgan privilegios con el comando grant:

Podemos especificar privilegios diferentes para cada columna o grupos de columnas:

MySQL proporciona una gran variedad de tipos de privilegios.

•    Privilegios relacionados con tablas: alter, create, delete, drop, index, insert, select, update

•    Algunos privilegios administrativos: file, proccess, super reload, replication client, grant option, shutdown

•    Algunos privilegios para fines diversos: lock tables, show databases, create temporary tables.

El privilegio all otorga todos los privilegios exceptuando el privilegio grant option. Y el privilegio usage no otorga ninguno, lo cual es útil cuando se desea, por ejemplo, simplemente cambiar la contraseña:

 

 

Tipos de privilegios en MySQL

Tipo de privilegio	Operación que permite
all [privileges]	Otorga todos los privilegios excepto grant option
usage	No otorga ningún privilegio
alter	Privilegio para alterar la estructura de una tabla
create	Permite el uso de create table
delete	Permite el uso de delete
drop	Permite el uso de drop table
index	Permite el uso de index y drop index
insert	Permite el uso de insert
select	Permite el uso de select
update	Permite el uso de update
file	Permite le uso de select . . . into outfile y load data infile
process	Permite el uso de show full procces list
super	Permite la ejecución de comandos de supervisión
reload	Permite el uso de flush
replication client	Permite preguntar la localización de maestro y esclavo
replication slave	Permite leer los binlog del maestro
grant option	Permite el uso de grant y revoke
shutdown	Permite dar de baja al servidor
lock tables	Permite el uso de lock tables
show tables	Permite el uso de show tables
create temporary tables	Permite el uso de create temporary table

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

En entornos grandes, es frecuente encontrarse en la necesidad de delegar el trabajo de administrar un servidor de bases de datos para que otros usuarios, además del administrador, puedan responsabilizarse de otorgar privilegios sobre una base de datos particular. Esto se puede hacer en MySQL con el privilegio grant option:

El mismo resultado se puede obtener con la siguiente sintaxis alternativa:

 

De este modo el usuario operador podrá disponer de todos los privilegios sobre la base de datos demo, incluido el de controlar el acceso a otros usuarios.

* Secure Sockets Layer

MySQL puede establecer conexiones seguras encriptándolas mediante el protocolo SSL*; de esta manera, los datos que se transmiten (tanto la consulta, en un sentido, como el resultado, en el otro) entre el cliente y el servidor estarán protegidos contra intrusos. Para especificar que un usuario debe conectarse obligatoriamente con este protocolo, se utiliza la cláusula require:

Las conexiones encriptadas ofrecen protección contra el robo de información, pero suponen una carga adicional para el servicio, que debe desencriptar la petición del cliente y encriptar la respuesta (además de un proceso más largo de negociación al conectar), por ello, merman el rendimiento del SGBD.

s

 

Los recursos físicos del servidor siempre son limitados: si se conectan muchos usuarios al mismo tiempo al servidor y realizan consultas o manipulaciones de datos complejas, es probable que pueda decaer el rendimiento notablemente. Una posible solución a este problema es limitar a los usuarios el trabajo que pueden pedir al servidor con tres parámetros:

•    Máximo número de conexiones por hora.

•    Máximo número de consultas por hora.

•    Máximo número de actualizaciones por hora.

La sintaxis de estas limitaciones es como se muestra a continuación:

El comando  revoke  permite eliminar privilegios otorgados con  grant a los usuarios. Veamos un ejemplo representativo:

Al ejecutar este comando se le retiran al usuario visitante todos sus privilegios sobre todas las bases de datos, cuando se conecta desde localhost.

El comando anterior no retira todos los privilegios del usuario visitante, sólo se los retira cuando se conecta desde localhost. Si el usuario se conecta desde otra localidad (y tenía permiso para hacerlo) sus privilegios permanecen intactos.

Antes de proceder a la eliminación de un usuario, es necesario asegurarse de que se le han quitado primero todos sus privilegios. Una vez asegurado este detalle, se procede a eliminarlo mediante el comando drop user:

MySQL almacena la información sobre los usuarios y sus privilegios en una base de datos como cualquier otra, cuyo nombre es mysql. Si exploramos su estructura, entenderemos la manera como MySQL almacena la información de sus usuarios y privilegios:

Es posible realizar modificaciones directamente sobre estas tablas y obtener los mismos resultados que si utilizáramos los comandos grant, revoke, set password o drop user:

El comando flush privileges solicita a MySQL que vuelva a leer las tablas de privilegios. En el momento de ejecutarse, el servidor lee la información de estas tablas sobre privilegios. Pero si se han alterado las tablas manualmente, no se enterará de los cambios hasta que utilicemos el comando flush privileges.

 

 

Tablas de la base de datos mysql

Tabla	Contenido
user	Cuentas de usuario y sus privilegios globales
db	Privilegios sobres bases de datos
tables_priv	Privilegios sobre tablas
columns_priv	Privilegios sobre columnas
host	Privilegios de otros equipos anfitriones sobre bases de datos

El acceso directo a las tablas de privilegios es útil en varios casos; por ejemplo, para borrar un usuario del sistema en las versiones de MySQL anteriores a la 4.1.1:

No es posible eliminar mediante un solo comando revoke todos los privilegios de un usuario.

Ejemplo

Se otorgan derechos a un usuario con dos comandos grant.

Observando el contenido de la base de datos de privilegios, podemos entender el comportamiento de los comandos grant y revoke. Primero asignamos privilegios para usar el comando select al usuario visitante con dos comandos grant: el primero de ellos le permite el ingreso desde el servidor nuestra-ong.org y el segundo le otorga el mismo tipo de privilegio, pero desde cualquier equipo en Internet.

Consultando la tabla user de la base de datos de privilegios, podemos observar los valores ’Y’ en la columna del privilegio select.

Ahora solicitamos eliminar el privilegio select de todas las bases de datos y de todos los equipos en Internet.

En la tabla user observamos que, efectivamente, se ha eliminado el privilegio para visitante@’%’ pero no para 'visitante@nuestra-ong.org'. MySQL considera que son direcciones diferentes y respeta los privilegios otorgados a uno cuando se modifica otro.

Un mecanismo que permite realizar la copia de los archivos del servidor sin necesidad de detener el servicio es el script 'mysqlhotcopy'. El script está escrito en Perl y bloquea las tablas mientras realiza el respaldo para evitar su modificación. Se usa de la siguiente manera:

En este caso, creará un directorio /algun_directorio/demo con todos los archivos de la base de datos.

El comando mysqlhotcopy puede recibir sólo el nombre de una base de datos como parámetro:

En este caso, creará un directorio /var/lib/mysql/demo_copy.

Este método no funciona para tablas con el mecanismo de almacenamiento tipo InnoDB.

Las dos opciones anteriores representan copias binarias de la base de datos. El comando mysqldump, en cambio, realiza un volcado de las bases de datos pero traduciéndolas a SQL; es decir, entrega un archivo de texto con todos los comandos necesarios para volver a reconstruir las bases de datos, sus tablas y sus datos. Es el método más útil para copiar o distribuir una base de datos que deberá almacenarse en otros servidores.

El comando mysqldump ofrece multitud de parámetros para modificar su comportamiento  o  el  tipo  de  volcado  generado:  por  defecto,  genera  sentencias SQL, pero puede generar ficheros de datos tipo CSV u otros formatos. También podemos especificarle que haga el volcado de todas las bases de datos o que sólo vuelque los datos y no la creación de las tablas, etc.

Las primeras líneas del archivo demo.sql según el ejemplo anterior tendrían el siguiente aspecto:

La ventaja de utilizar mysqldump es que permite que los archivos puedan ser leídos (y modificados) en un simple editor de textos, y pueden ser utilizados para migrar la información a otro SGBD que soporte SQL. Además soporta todos los tipos de tablas. La desventaja es que su procesamiento es lento y los archivos que se obtienen son muy grandes.

En algún momento, sea por el motivo que sea, necesitaremos realizar la restauración de nuestras bases de datos.

Si tenemos una copia binaria del directorio de datos, bastará con copiarla al directorio original y reiniciar el servidor:

 

Es importante restaurar también el dueño y el grupo de los archivos de datos, para tener los accesos correctamente establecidos. En este ejemplo se adopta el supuesto que el usuario mysql es el que ejecuta el servidor mysqld.

La restauración de un archivo SQL obtenido con mysqldump, se realiza desde el cliente mysql, la base de datos debe existir, ya que el archivo demo.sql no la crea por defecto.

El programa myisamchk es una utilidad en línea de comandos que se incluye con la distribución de MySQL y sirve para reparar tablas tipo MyISAM. Para utilizarlo con seguridad el servidor no debe estar ejecutándose y se recomienda realizar un respaldo del directorio de datos antes de su utilización.

Recibe como parámetro principal los archivos .MYI correspondientes a las tablas que hay que revisar; es decir, myisamchk no conoce la ubicación del directorio de datos. Por ejemplo, si el directorio de datos está ubicado en /val/ lib/mysql, las siguientes serían dos maneras de realizar una comprobación de los archivos de la base de datos demo:

Se pueden revisar todas las bases de datos utilizando ’*’ para denominar el directorio de la base de datos:

Para realizar una comprobación rápida, el manual sugiere utilizar el siguiente comando:

Y para realizar la corrección de las tablas corruptas, el manual sugiere la sintaxis siguiente:

Nota

En la práctica con estas opciones se logran corregir los errores más comunes. Para conocer otras opciones de recuperación con myisamchk, podéis consultar el manual que acompaña a la distribu- ción de MySQL.

 

 

 

 

 

 

Las opciones dadas por -O se refieren al uso de memoria, que permiten acelerar de forma notoria el proceso de reparación.

 

--force reinicia myisamchk con el parámetro  --recover cuando encuentra algún error.

--updatestate almacena información sobre el resultado del análisis en la tabla MYI.

La indexación es la principal herramienta para optimizar el rendimiento general de cualquier base de datos. Es también la más conocida por los usuarios de servidores MySQL y, paradójicamente, su no utilización es una de las principales causas de bajo rendimiento en servidores de bases de datos.

Muchos administradores y diseñadores simplemente parecen olvidar usar índices para optimizar los accesos a las bases de datos. Por otro lado, algunas personas tienden a indexar todo, esperando que de esta manera el servidor acelere cualquier tipo de consulta que se le solicite. En realidad, esta práctica puede causar una disminución en el rendimiento, sobre todo en lo que respecta a inserciones y modificaciones.

Para ver las ventajas de utilizar índices, analizaremos en primer término una simple búsqueda en una tabla sin índice alguno:

•    El constante acceso de escritura de una tabla la mantiene desordenada.

•    La ordenación de una tabla es una operación costosa: el servidor tendría que detenerse un tiempo considerable para ordenar sus tablas.

•    Muchas tablas tienen más de un criterio de ordenación: ordenar según una columna implica desordenar otra.

•    La inserción y eliminación de datos sin alterar el orden en una tabla es costosa: la inserción de un registro en una tabla grande implicaría una larga espera en la actualización de la misma.

•    Si se opta por mantener la tabla desordenada (que es la opción más viable), una búsqueda implicaría forzosamente un recorrido secuencial (también denominado full scan), registro por registro.

El uso de índices en la ordenación de las bases de datos ofrece las ventajas siguientes:

•    Permite ordenar las tablas por varios criterios simultáneamente.

•    Es menos costoso ordenar un archivo índice, porque incluye sólo referencias a la información y no la información en sí.

•    El coste de inserción y eliminación es menor.

•    Con los registros siempre ordenados se utilizaran algoritmos mucho más eficientes que el simple recorrido secuencial en las consultas.

El uso de índices también comporta alguna desventaja:

•    Los índices ocupan espacio en disco.

•    Aún teniendo registros pequeños, el mantener en orden un índice disminuye la velocidad de las operaciones de escritura sobre la tabla.

A pesar de estos inconvenientes, la utilización de índices ofrece mayores ventajas que desventajas, sobre todo en la consulta de múltiples tablas, y el aumento de rendimiento es mayor cuanto mayor es la tabla.

Consideremos por ejemplo una consulta sobre las tablas A, B, y C, independientemente del contenido de la cláusula where, las tres tablas se deben de combinar para hacer posible posteriormente el filtrado según las condiciones dadas:

Consideremos que no son tablas grandes, que no sobrepasan los 1.000 registros. Si A tiene 500 registros, B tiene 600 y C 700, la tabla resultante de la consulta  anterior  tendrá  210  millones  de  registros.  MySQL  haría  el  producto cartesiano de las tres tablas y, posteriormente, se recorrería la relación resultante para buscar los registros que satisfacen las condiciones dadas, aunque al final el resultado incluya solamente 1.000 registros.

Si utilizamos índices MySQL los utilizaría de una forma parecida a la siguiente:

•    Tomaría cada uno de los registros de A.

•    Por cada registro de A, buscaría los registros en B que cumpliesen con la condición A.a = B.b. Como B está indexado por el atributo 'b', no necesitaría hacer el recorrido de todos los registros, simplemente accedería directamente al registro que cumpliese la condición.

•    Por cada registro de A y B encontrado en el paso anterior, buscaría los registros de C que cumpliesen la condición B.b = C.c. Es el mismo caso que en el paso anterior.

Comparando las dos alternativas de búsqueda, la segunda ocuparía cerca del 0,000005% del tiempo original. Por supuesto que sólo se trata de una aproximación teórica, pero adecuada para comprender el efecto de los índices en las consultas sobre bases de datos.

El índice ideal debería tener las siguientes características:

•    Los registros deberían ser lo más pequeños posible.
•    Sólo se debe indexar valores únicos.

Analicemos cada recomendación:
•    Cuanto más pequeños sean los registros, más rápidamente se podrán cambiar de lugar (al insertar, modificar o borrar filas), además, en un momento dado, el índice puede permanecer en memoria. Consideremos las dos definiciones posibles:

En esta tabla el índice se realiza sobre nombre, que es un campo de 30 caracteres, y se utiliza como clave para hacer los 'joins' con otras tablas.

 

Ahora considérese la siguiente alternativa:

Se agrega una columna que servirá como identificador de la empresa. Desde el punto de vista de rendimiento implica una mejora, ya que el índice se realiza sobre números enteros, por lo tanto, ocupará menos espacio y funcionará más rápido.

•    Consideremos el índice siguiente, creado para disminuir la necesidad de efectuar accesos a la tabla:

Si consideramos que un índice se crea para evitar la necesidad de recorrer la tabla, veremos que el índice creado es prácticamente inútil, ya que alguno de los valores ocurre el 50% o más de las veces: para encontrar todos los resultados hay que recorrer gran parte de la tabla. MySQL no utiliza los índices que implican un 30% de ocurrencias en una tabla.

Aun así, y exceptuando casos exagerados como este último, puede ser interesante indexar una tabla por algún atributo que no sea único, si ese atributo se utiliza para ordenar los resultados. También puede ser conveniente crear un índice por varios atributos simultáneamente si se usan todos en alguna consulta en la cláusula ORDER BY.

* Memoria intermedia de acceso rápido.

El servidor MySQL incluye la posibilidad de utilizar una cache* con los resultados de las últimas consultas para acelerar la velocidad de respuesta. Esta solución  es  útil  cuando  las  tablas  tienen  relativamente  pocos  cambios  y  se realizan los mismos tipos de consultas. El funcionamiento de la cache se basa en las premisas siguientes:

•    La primera vez que se recibe una consulta se almacena en la cache.

•    Las siguientes veces la consulta se realiza primero en la cache; si tiene éxito, el resultado se envía inmediatamente.

La cache tiene las siguientes características:

•    El servidor compara el texto de la consulta; aunque técnicamente sea igual si difiere en uso de mayúsculas-minúsculas o cualquier otro cambio, no se considera la solicitud idéntica y no será tratada por la cache.

•    Si alguna tabla incluida en alguna consulta cambia, el contenido de la consulta es eliminado de la cache.

La configuración de la cache se realiza a través de variables globales:

•    query_cache_limit. No almacena resultados que sobrepasen dicho tamaño. Por omisión es de 1M.

•    query_cache_size. Tamaño de la memoria cache expresada en bytes. Por omisión es 0; es decir, no hay cache.

•    query_cache_type. Puede tener tres valores: ON , OFF o DEMAND 

tipos de cache

Valor	Tipo	Significado
0	OFF	Cache desactivado
1	ON	Cache activado
2	DEMAND	Sólo bajo solicitud explicita

 

 

 

 

 

Cuando la cache del servidor esta en modo DEMAND, se debe solicitar explícitamente que la consulta utilice o no la cache:

El equipo maestro debe tener acceso por red. Antes de realizar la configuración de los servidores maestro y esclavo es necesario realizar las siguientes tareas:

•    Asegurarse de que en ambos está instalada la misma versión de MySQL.

•    Asegurarse de que ninguno de los servidores atenderá peticiones durante el proceso de configuración.

•    Asegurarse de que las bases de datos del servidor maestro han sido copiadas manualmente en el servidor esclavo, de manera que en ambos se encuentre exactamente la misma información.

•    Asegurarse de que ambos atienden conexiones vía TCP/IP. Por seguridad, esta opción está desactivada por omisión. Para activarla se debe comentar la línea skip_networking en el archivo de configuración /etc/my.cnf

En el servidor maestro creamos una cuenta de usuario con permisos de replicación para autorizar, en el servidor maestro, al nuevo usuario para realizar réplicas:

Replicador es el nombre del nuevo usuario.

Esclavo.empresa.com es la dirección del servidor esclavo.

’Secreto’ es la contraseña.

 

El servidor maestro llevará un archivo de registro 'binlog' donde se registrarán todas las solicitudes de actualización que se realicen en las bases de datos. Para activar la creación de este archivo debemos editar el archivo /etc/my.cnf y agregar las siguientes líneas en la sección [mysqld]:

El servidor maestro debe identificarse con un id, en este caso será el número 1. a continuación, reiniciamos el servidor:

Finalmente, consultamos el nombre del archivo 'binlog' y la posición de compensación (estos datos son necesarios para configurar el esclavo):

 

En el servidor esclavo, editamos el archivo /etc/my.cnf y agregamos, al igual que en el maestro, la activación del archivo 'binlog' y un identificador del servidor (que debe ser distinto del identificador del servidor maestro):

Reiniciamos el servidor esclavo:

Configuramos los datos del maestro en el servidor esclavo:.

El último paso es iniciar el servidor esclavo:

Y ya tendremos el servidor esclavo funcionando.

La utilidad mysqlimport que se incluye en la distribución puede realizar el mismo trabajo que load data. Estos son algunos de sus parámetros:

Estos son algunos de los argumentos de mysqlimport para realizar las tareas equivalentes a la sentencia load data:

La forma más simple para exportar datos es redireccionando la salida del cliente mysql. El parámetro -e permite ejecutar un comando en modo de procesamiento por lotes. MySQL detecta si la salida es en pantalla o está redireccionada a un archivo y elige la presentación adecuada: con encabezados y líneas de separación para la salida en pantalla, y sin encabezados y con tabuladores para un archivo:

La sentencia select también cuenta con una opción para realizar la tarea inversa de la sentencia load data:

La utilidad mysqldump realiza el volcado de bases de datos y puede utilizarse para transportar datos de una base a otra que también entienda SQL. Sin embargo, el archivo debe ser editado antes de utilizarse, ya que algunas opciones son exclusivas de MySQL. Por lo general, basta con eliminar el tipo de tabla que se especifica al final de un comando create table.

El siguiente comando realiza el vaciado completo de la base de datos demo:

En algunos casos, los comandos insert son suficientes y no necesitamos las definiciones de las tablas.

El siguiente comando realiza un vaciado de la tabla proveedores de la base de datos demo filtrando la salida con el comando grep de UNIX que selecciona sólo las líneas que contienen la palabra INSERT. De este modo, el archivo proveedores-insert.txt contiene exclusivamente comandos insert: