Mod BD UD8 ADMINIST

De MediaWiki
Ir a la navegación Ir a la búsqueda

Introducción

  • En esta unidad vamos a ver diferentes actividades orientadas a la administración y mejora de acceso a los datos en una base de datos relacional empleando Mysql.
Veremos:
  • El uso de índices para mejorar la velocidad de acceso a datos.
  • Creación de eventos: Los eventos van a permitir ejecutar código SQL y que este se ejecute cada cierto tiempo o en una fecha-hora determinada.
  • Creación de usuarios y privilegios: Durante todo este curso hemos realizado todas las operaciones siendo root, un usuario creado por defecto en Mysql y que tiene todos los permisos. Veremos que esto no es lo adecuado y que debemos de limitar el acceso a los recursos en base a los privilegios que tenga cada usuario.
  • Copias de seguridad: Aprenderemos cómo crear copias de seguridad de nuestra base de datos y como recuperarla en caso de catástrofe.
  • Importación / Exportación: También relacionado con el punto anterior, veremos como importar y exportar nuestra base de datos a diferentes formatos.


  • Para aprender todo lo anterior, vamos a abandonar la base de datos con la que trabajamos en la UD7, y haremos uso de una base de datos de prueba que suministra Mysql de nombre employees.
Dicha base de datos no es muy compleja (sólo tiene 6 tablas) pero incorpora millones de registros que nos va a permitir realizar pruebas de 'optimización' de acceso a la base de datos.
Vamos a instalar la base de datos employees.
Mysql sp 00.jpg


Los pasos para instalarla los tenéis en este enlace.
Básicamente tenemos que:
  • Descargar de github la base de datos. Desde Linux, en una consola podemos escribir la orden: wget https://github.com/datacharmer/test_db/archive/master.zip
  • Descomprimimos el archivo descargado desde consola con la orden: unzip master.zip
  • Dentro del directorio test-db-master/ se encuentra el archivo employees.sql que es el que crea todas las tablas y añade los datos a cada una de ellas. Para ejecutarlo, ejecutaremos desde consola la orden: sudo mysql -uroot -p < employees.sql (suponemos que root tiene password). Una vez hecho esto ya tenemos la base de datos de nombre employees creada.




Indices

Nota aclaratoria: Esta sección está pensada para alumnos que desarrollen aplicaciones y necesiten optimizar sus consultas.

En este enlace y este otro, que forman parte del curso Mysql 5.7 de esta Wiki introduce aspectos relacionados con la administración que no serán comentados en esta sección.


  • La función principal que tiene un índice es la de acelerar las consultas SELECT que se hagan sobre una base de datos.
En Mysql disponemos de el registro de consultar lentas que podemos activar para determinar cuales son las consultas que más ralentizan el Mysql, analizarlas y ver si podemos mejorarlas cambiándolas o creando índices.
  • Un índice es una estructura de datos en la cual los valores guardados son los datos de una o más columnas de una tabla de forma ordenada. Cada entrada del índice apuntará a la ubicación del registro en la tabla.
De esta forma, la búsqueda de registros por un campo indexado será mucho más rápida que si no lo está.
  • Como en todo, el uso de registros lleva aparejado ciertos problemas (sino fuera así podríamos crear índices para todas las columnas de una tabla):
  • Es una estructura de datos que ocupa espacio a mayores del espacio de la propia tabla.
  • En caso de operaciones de inserción, borrado o modificación el índice se debe rehacer con la consiguiente carga de trabajo para el gestor.


IMPORTANTE:

  • Toda clave primaria debe tener un índice asociado (de hecho se crea automáticamente).
Toda clave foránea debe de tener asociado un índice (si lo hacemos gráficamente ya crea el índice, pero si somos nosotros los que ejecutamos la orden CREATE TABLE tendremos que crear un índice por cada columna que sea clave foránea).


  • Un ejemplo obtenido de la wiki:
Mysql index 1.png
En este ejemplo, la clave primaria tiene asociado un índice de tipo BTREE, en el que las claves están ordenadas, estando al lado izquierdo las menores y al lado derecho las mayores con respecto al valor referenciado de un nodo dado.


  • ¿ Cuando voy a hacer uso de índices ?
  • En cláusulas WHERE
  • En cláusulas ORDER BY
Si tengo una orden SQL como:
SELECT nombre FROM ALUMNOS
WHERE edad between 10 and 20
Tardará menos en ejecutarse si tengo un índice asociado a la edad que si no lo tengo ya que no tendrá que recorrer todas las filas comprobando la cláusula Where.



Crear índices

  • Podemos crear un índice de tres formas:


  • Veamos un ejemplo sobre una supuesta tabla ALUMNOS sobre la que queramos indexar su nombre:
CREATE INDEX idx_Alumnos_nombre ON ALUMNOS (nombre)
Siendo ALUMNOS el nombre de la tabla y nombre la columna a indexar.
ALTER TABLE ALUMNOS ADD INDEX idx_Alumnos_nombre (nombre)
Siendo Alumnos el nombre de la tabla y nombre la columna a indexar.


  • Algunos de los modificadores que podemos añadir a la creación de un índice:
  • UNIQUE: índice formado por campos cuyo valor no puede repetirse.
  • PRIMARY: Es el índice que conforma la clave primaria de una tabla. Los valores no pueden repetirse. Es recomendable que sea numérica y en caso de no existir, se debe crear una columna de tipo 'autonumérico'.
  • full-text: Es un tipo de índice 'especial' que se aplica a campos de texto de gran tamaño, como el tipo TEXT y sus variantes, aunque también puede realizarse sobre char y varchar. Al crear un índice de este tipo, cada una de las palabras del texto es 'indexada' para poder hacer búsquedas en las que se busca sólo alguna de las palabras del mismo. Esto se realiza haciendo uso de la orden SQL MATCH(). A diferencia de LIKE, este comando busca por palabras y permite buscar en varias columnas, indicar si deben aparecer ciertas palabras en la columna o que no aparezcan ciertas otras,...
  • SPATIAL: Son índices usados para tipos de datos espaciales como LINE o CURVE.


  • Indicar que cuando creamos una tabla, también podemos 'crear índices' de la forma:
CREATE TABLE `dept_emp` (
  `emp_no` int(11) NOT NULL,
  `dept_no` char(4) NOT NULL,
  `from_date` date NOT NULL,
  `to_date` date NOT NULL,
  PRIMARY KEY (`emp_no`,`dept_no`),
  KEY `dept_no` (`dept_no`),
  CONSTRAINT `dept_emp_ibfk_1` FOREIGN KEY (`emp_no`) REFERENCES `employees` (`emp_no`) ON DELETE CASCADE,
  CONSTRAINT `dept_emp_ibfk_2` FOREIGN KEY (`dept_no`) REFERENCES `departments` (`dept_no`) ON DELETE CASCADE
) ENGINE=InnoDB;
Se puede poner KEY o INDEX.
Fijarse que no crea un índice para emp_no a pesar de ser clave foránea. Esto es así ya que al formar parte de la clave primaria y estar en primer lugar, Mysql ya crea un índice para dicha columna.




Modificar índices

  • No es posible.
Podemos utilizar la orden SQL ALTER TABLE con la opción ALTER INDEX para hacer el índice visible o invisible.
Esto hará que el optimizador de consultas no lo use (invisible) o lo tenga en cuenta (visible).
Sólo se puede utilizar en NDB CLUSTER.


  • Un ejemplo:
ALTER TABLE Alumnos ALTER INDEX idx_Alumnos_nombre INVISBLE
Siendo Alumnos el nombre de la tabla.



Borrar índices

DROP INDEX idx_Alumnos_nombre ON Alumnos
Siendo Alumnos el nombre de la tabla.



Tipos de índices

Parciales

  • Como comentamos en la introducción, los índices van a ocupar espacio en disco.
Una columna de 200 caracteres de ancho (200 bytes) y con 5 millones de registros, si hacemos un índice sobre ella, ocupará 1.000.000.000 de bytes = 953MB
  • Para evitarlo podemos crear un índice parcial, es decir, un índice sobre una parte del tamaño de la columna.
CREATE INDEX idx_Alumnos_direccion ON Alumnos (direccion(100))
En este caso estamos creando un índice de la mitad del tamaño de la columna (100 caracteres) por lo tanto ocupará 953/2 = 476MB
  • Se pueden crear sobre columnas de tipo CHAR, VARCHAR y TEXT.
En el caso de TEXT es obligatorio indicarlo.
También con los tipos de datos BINARY, VARBINARY y BLOG, pero en este caso indicamos el número de bytes. También es obligatorio.



Multicolumna

  • Este tipo de índices abarca más de una columna.
Un caso típico podría ser el de columnas nombre y apellidos.
Si quiero crear un índice por apellidos y dentro de apellidos que ordene por nombre, crearía un único índice con las dos columnas, de la forma:
CREATE INDEX idx_Alumnos_nombre_apellidos ON Alumnos (apellidos(100),nombre)
Nota Fijarse que el orden de las columnas en el índice es importante. No es lo mismo crear un índice de 'nombre-apellidos' que de 'apellidos-nombre'.


Veremos en el siguiente punto de la Wiki cual es el mejor orden


Secundarios o clusters

  • Cuando creamos una clave primaria, realmente estamos creando un índice sobre las columnas que conforman la clave primaria, un tipo de índice que impide que haya dos valores iguales.
Al crearlo, Mysql ordena físicamente los registros para que coincidan con el índice, de tal forma que índice y registro están 'unidos'. El registro se guarda junto a su clave primaria.
Así, si tengo creado como índice de clave primaria una columna id, físicamente los registros estarán:
ID-------Nombre
1--------Angel
2--------Maria
3--------Juan
4--------Ana
Este tipo de índice se denomina cluster.


  • En una tabla, como vimos, podemos crear otros índices. Cuando usamos INNODB como motor de almacenamiento, éstos guardan el valor de la clave primaria para buscar el registro, a parte del valor del índice creado. Este tipo de índices se denominan índices secundarios o no clusterizados.
En el ejemplo anterior, si creamos un índice sobre la columna Nombre tendremos:
Nombre-------ID
Ana----------4
Angel--------1
Juan---------3
Maria--------2
Para recuperar un registro cuando usamos un índice secundario, necesitamos dos operaciones de disco, una para buscar el valor en la tabla del índice y otra para buscar el registro a partir de la clave primaria.
En el motor MyISAM pasa lo mismo, pero la diferencia es que los índices se guardan en archivos separados y el valor asociado al índice no es la clave primaria, sino el valor desplazamiento (offset) del registro en la tabla.
  • Visto lo anterior es importante elegir bien la clave primaria:
  • Debemos elegir un campo que no implique modificaciones, ya que será necesario una reordenación de los registro.
  • Además es mejor que tenga un tamaño pequeño, ya que, si por ejemplo es una cadena de 100 caracteres, estamos guardando en todos los índices secundarios 100 caracteres en cada entrada del índice.



Optimizando los índices

  • Los índices no pueden ser actualizados y es necesario borrarlos y volverlos a crear.
Además, los índices generan ciertas estadísticas que son utilizadas por el optimizador de consultas para determinar cual es la mejor forma de obtener los resultados de una consulta.
  • Por estas dos razones, debemos de utilizar uno de estos dos comandos:
  • El comando OPTIMIZE TABLE cuando trabajamos con tablas que han sufrido muchas operaciones modificando las columnas asociadas a sus índices (borrados, actualizaciones, inserciones).
Este comando va a desfragmentar la tabla y a actualizar y reordenar sus índices. Sólo se puede aplicar sobre motores INNODB, MYISAM y Archive.
Tendrá el efecto de recuperar el espacio de disco que una tabla ya no usa (después de hacer un borrado de muchas filas).
Recrear los índices y volver a generar la información necesaria para que el optimizador de consultas determine cuando hacer uso del mismo.
  • El comando ANALYZE TABLE cuando trabajamos con tablas que han sufrido muchas operaciones modificando las columnas asociadas a sus índices (borrados, actualizaciones, inserciones).
A diferencia del anterior, este comando sólo recrea los índices de la tabla pero no recupera el espacio de disco que ya no utilice.
OPTIMIZE TABLE en el caso del motor INNODB, lo que hace 'realmente' es crear una tabla copia de la tabla a optimizar, borra la original y renombra la nueva, haciendo después un ANALYZE TABLE.
Por lo tanto este comando sirve también para 'reclamar' el espacio que ya no utiliza una tabla (al borrarse registros, el tamaño físico de la tabla se mantiene).
Hay que tener cuidado ya que va a necesitar el doble de tamaño en disco (de lo que ocupa la tabla) para realizar la operación (en el caso de recrear los índices).
La reducción de espacio sólo funcionará si la variable del sistema innodb_file_per_table está a ON (valor por defecto).
Nota:
  • Cuando se ejecuta este comando con el motor InnoDB saldrá un aviso con el siguiente texto: Table does not support optimize, doing recreate + analyze instead.
No hacer caso al mismo ya que lo que indica es que el motor InnoDB no va a hacer lo que se hacía con el motor MyISAM para optimizar la tabla.
  • Debemos de tener cuidado cuando ejecutamos el comando ya que la tabla queda 'bloqueada' hasta que finalice la optimización.



Por defecto. si está activo el registro binario de log, las operaciones realizadas por el comando anterior son guardadas en dicho fichero. Si queremos que esto no ocurra, tendremos que llamar al comando con la opción 'LOCAL' o 'NO_WRITE_TO_BINLOG'. Esto es así para que en caso de un entorno de maestro-esclavos, los cambios no sean replicados a los esclavos.


  • Por tanto, tendremos que ejecutar operaciones de optimización sobre tablas que se modifiquen habitualmente (operaciones de borrado, inserción y modificación sobre los datos asociados al índice).
  • Veamos un ejemplo:
OPTIMIZE TABLE ALUMNOS;
ANALYZE TABLE ALUMNOS;


  • Según esta documentación, en el caso de tener índices secundarios es mejor borrarlos, optimizar la tabla y volver a crearlos.



Optimizando los tipos de datos

  • Siempre es preferible valores numéricos para identificar las filas que valores de cadena.
  • Si la información a guardar puede ser guardada en formato numérico o cadena, es preferible que sea numérica.
  • Con columnas inferiores en tamaño a 8KB es mejor hacer uso del tipo de datos varchar que blob.
  • Si habitualmente en una tabla se disponen de columnas a las cuales raramente se va a acceder, es mejor mover dichas columnas a otra tabla y relacionarlas con una clave primaria-foránea con la tabla original.



Optimizando las consultas


Caso 1: Parte Where con una única condición
  • La sentencia SQL es del tipo:
1 SELECT columnas
2 FROM Tabla
3 WHERE col=valor
Para este tipo de sentencias es necesario crear un índice sobre la columna a la que aplicamos la condición.
Veamos un ejemplo:
1 SELECT *
2 FROM employees.employees
3 where hire_date='1986-06-26';
Si ejecutamos esta sentencia dos veces, una sin el índice creado y la siguiente vez con un índice creado sobre la columna hire_date nos dará este resultado:
Mysql indices opt 1.jpg
Podemos comprobar como la velocidad (columna Duration) es mucho menor en el segundo caso gracias al uso del índice.


  • Podemos ver en este enlace un ejemplo en el que el uso de un índice aplicado a una columna es peor que no tenerlo (de hecho Mysql tiene un optimizador y sabe que no debe hacer uso de él). Fijarse que la sentencia count es sobre la columna 'name' que no se forma parte de la estructura del índice.



Caso 2: Parte Where con una varias condiciones de tipo AND
Nota: Partimos de un ejemplo de dos columnas, aplicándose los mismos conceptos a 3 o más columnas.
  • La sentencia SQL es del tipo:
1 SELECT columnas
2 FROM Tabla
3 WHERE col1=valor1 and col2=valor2
En este caso se debe de 'cubrir' todas las columnas de la parte Where.
Aquí podemos tener dos posibilidades:
  • índice sobre las columnas col1,col2
  • índice sobre las columnas col2,col1
Fijarse que el orden es importante, no es lo mismo ordenar por apellidos y dentro de cada apellido por el nombre, que ordenar por el nombre y por cada nombre, ordenar todos los apellidos.
¿ Cual debemos elegir ?
Como siempre vamos a dar un consejo 'general' pero que dependiendo de los datos puede que no sea la mejor opción.
Si sobre la base de datos tenemos, a parte de la consulta anterior, consultas del tipo:
1 SELECT columnas
2 FROM Tabla
3 WHERE col1=valor1
Debemos crear el índice con las columnas col1,col2.
Este índice cubre las dos consultas anteriores y otras, siempre que se busque por col1:
 1 SELECT columnas
 2 FROM Tabla
 3 WHERE col1=valor1
 4 
 5 SELECT columnas
 6 FROM Tabla
 7 WHERE col1=valor1 and col2=valor2
 8 
 9 SELECT columnas
10 FROM Tabla
11 WHERE col2=valor2 and col1=valor1
12 
13 
14 SELECT columnas
15 FROM Tabla
16 WHERE col1=valor1 and (col2=valor2 or col2=valor3)
17 
18 SELECT columnas
19 FROM Tabla
20 WHERE col1=valor1 and col2>=valor2 and col2<=valor3


Si por el contrario, tenemos consultas del tipo:
1 SELECT columnas
2 FROM Tabla
3 WHERE col2=valor2
4 
5 SELECT columnas
6 FROM Tabla
7 WHERE col1=valor1 and col2=valor2
Escogeremos el índice: col2,col1.



Nota::
  • Siempre que tengamos una consulta SQL en la que la parte where afecte a más de una columna, será mejor hacer un único índice sobre todas las columnas del where que el realizar múltiples índices sobre cada columna individual.
  • Como dije al principio, esta regla puede no ser correcta dependiendo de los datos. Si la condición col1='valor1' devuelve casi todos los registros de la tabla, será mejor hacer índice a 'col2,col1' no hacer índice sobre col1 (explicamos a continuación por qué)


  • Debemos de tener en cuenta otro factor a la hora de elegir el orden, que es el de la cardinalidad.
Este factor indica cuantos valores diferentes guarda un índice.
La idea es que cuantos más valores diferentes haya, mejor, ya que el número de filas que devolverá el índice debería ser menor, al seleccionar filas en base a algún criterio.
Para saber la cardinalidad de una columna podemos ejecutar la siguiente orden SQL: SELECT COUNT(DISTINCT col).


Nota: Una desventaja que tiene esta opción es que en la recuperación de datos se moverá más por la estructura en árbol del índice si la condición devuelve muchos valores diferentes, mientras que si primero hacemos uso de la columna que tenga más duplicados, podrá devolver más filas con los mismos valores y por tanto no será necesario moverse tanto por la estructura de índice.
Por eso en varios sitios encontraréis que es mejor utilizar en primer lugar aquella columna que tenga más duplicados.
Son dos opciones contradictorias. Como consejo intentaremos escoger aquella opción que nos devuelve el menor número posible de resultados en base a los datos que tengamos de los datos empleados en la consulta.
Si no podemos saber este dato, escogeremos primero aquellas columnas que tengan la cardinalidad más alta.



  • Veamos un ejemplo:
1 SELECT *
2 FROM employees.employees
3 where hire_date='1986-06-26' and first_name='Shuzo'
Comprobamos cual de las dos columnas tiene la cardinalidad más alta:
Mysql indices opt 3.jpg
Como vemos la columna 'hire_date' tiene más valores diferentes (cardinalidad más alta).
Por lo tanto el índice que deberíamos crear sería: hire_date,first_name
Aún no vimos el comando 'explain' pero si creamos los dos tipos de índices sobre la tabla (hire_date,first_name y first_name,hire_date) podemos comprobar cual escoge Mysql:
Mysql indices opt 4.jpg
Como vemos escoge el formado por las columnas 'hire_date,first_name'.


Pero como estoy indicando desde el principio esto son 'líneas generales' pero que puede que necesiten modificarse dependiendo de los datos.
Por ejemplo, si ejecutamos la sentencia anterior de forma separada por cada columna del where y contamos el número de filas obtenemos:
Mysql indices opt 5.jpg
Como vemos hemos acertado en el sentido que devuelve menos filas el índice 'hire_date' que 'first_name',!!!!CON ESTOS DATOS!!!!'
Por eso Mysql escoge el índice formado por 'hire_date,first_date'
Pero si usamos datos que devuelvan más filas por la condición 'hire_date' que por la condición 'first_name', ¿ qué pasará ?, ¿ qué índice deberíamos escoger ?
Lo veremos más adelante con el comando explain.


Ejercicio Propuesto

En una base de datos se ejecutan este tipo de sentencias:
1 SELECT *
2 FROM employees.employees
3 where first_name='DATO1' and last_name='DATO2'
Analiza las columnas first_name, last_name y determina el orden de las columnas que conforman el índice


Nota: Si los resultados no son los esperados, probar a ejecutar la orden SQL 'Analyze table TABLA' o desde el Mysql WorkBench, seleccionando la tabla y pulsando el botón derecho, escoger la opción 'Table Inspector':
Mysql indices opt 12.jpg



Solución Ejercicio Propuesto

  • Si hacemos un count(distinct()) de cada columna podemos comprobar como la que tiene más valores diferentes es 'last_name'.
Por tanto el índice debería ser: last_name,first_name
Recordar: Esto es así porque presuponemos que el número de filas que devolverá el indice aplicando la primera columna será menor al tener menos valores repetidos, pero dependiendo de los datos, esto puede no ser cierto.
1 SELECT *
2 FROM employees.employees
3 where last_name='Rosch' and first_name='Shuzo'
Si averiguamos cuantas filas devuelve cada condición individualmente:
Mysql indices opt 6.jpg
Podemos comprobar como first_name devuelve más filas, por lo tanto es mejor escoger el índice: last_name,first_name como hemos decidido.
En este ejemplo, si dejamos a Mysql que elija el índice (teniendo los dos) escoge (no sé la razón, seguramente por el número de filas devuelto, que es muy bajo) el índice contrario:
Mysql indices opt 7.jpg
Sin embargo nuestra elección es la correcta (Mysql se equivoca) ya que si 'forzamos' a ejecutar la consulta con cada uno de los índices da mejor tiempo el índice 'last_name,first_name):
Mysql indices opt 8.jpg
De todas formas al ser el número de filas de diferencia entre un índice y otro no se notaría en este caso prácticamente diferencia y seguramente es por eso que Mysql escoge el otro índice.



Caso 3: Parte Where con una varias condiciones de tipo OR
  • Borramos todos los índices creados sobre la tabla 'employees' menos el de clave primaria.
  • Con una condición OR no tiene efecto un índice compuesto y tendremos tres posibilidades:
1 SELECT *
2 FROM tabla
3 WHERE col1=dato1 or col2=dato2
  • Crear un índice sobre col1
  • Crear un índice sobre col2
  • Crear un índice sobre col1 y crear otro índice sobre col2


Las dos primeras opciones no tienen sentido, ya que a pesar de tener un índice, Mysql tendría que recorrer toda la tabla para comprobar la condición que no tiene índice asociado.
La tercera opción podrá ser viable ya que Mysql a partir de la versión 5, puede aplicar varios índices haciendo una operación de combinación (en el comando explain aparece 'Using ....'.
Podéis consultar todo lo referente a combinación de índices en este enlace.
Pero al igual que en el Caso 2, tendremos que tener en cuenta la cardinalidad de cada columna.
Si esta es baja, no valdrá la pena crear un índice sobre la columna.


  • Veamos un ejemplo:
1 SELECT *
2 FROM employees.employees
3 WHERE first_name='Georgi' or hire_date='1985-11-21'
Creamos un índice sobre la columna 'first_name' y otro sobre la columna 'hire_date'
Recordar que hacer un índice sobre una de las columnas no tiene sentido
Con el comando Explain nos indica que está combinando los dos índices uniendo los resultados.
Mysql indices opt 9.jpg


Al igual que en todos los casos anteriores muchas veces vamos a depender de los datos guardados en las tablas.
En foros diversos establecen que que cuando una de las columnas (o ambas) tiene varios valores posibles es mejor cambiar la consulta y utilizar OR.
Podéis mirar el ejemplo propuesto en este enlace.
La idea es que toda instrucción OR se puede descomponer en dos órdenes SELECT unidas con el comando UNION de la forma:
1 SELECT *
2 FROM employees.employees
3 where first_name='Georgi' or hire_date='1985-11-21'
Es igual a:
1 SELECT *
2 FROM employees.employees
3 WHERE first_name='Georgi'
4 UNION
5 SELECT *
6 FROM employees.employees
7 WHERE hire_date='1985-11-21'
De esta segunda forma puede aplicar el índice individual a cada columna y hacer la unión de los dos resultados.


Pero por pruebas realizadas eso debería de ser así en versiones anterior de Mysql. En la actual y con la combinación de índices, siempre obtengo resultados más rápidos con el índice combinado.
De todas formas tener en cuenta esta posibilidad ya que puede ser que dependiendo de la consulta os convenga utilizar esta opción.



Ejercicio Propuesto

Borra todos los índices de la tabla employees menos el de clave Primaria.
Indica que índice crearías para optimizar este tipo de consultas:
1 SELECT *
2 FROM employees
3 WHERE (first_name like 'A%' and gender='M') or
4       (hire_date between '1993-01-01' and  '1995-01-01')




Solución Ejercicio Propuesto

La consulta está formada por dos partes separadas por el operador OR.
Con este tipo de operador intentaremos que haga uso de un índice combinado.
El primer índice será sobre la columna 'hire_date'
El segundo índice llega hacerlo sobre la columna 'first_name'. Tendríamos que escoger primero la columna que tuviera la cardinalidad más alta (first_name) y después la segunda columna. La columna 'gender' no va a compensar utilizarla ya que los datos están repartidos prácticamente al 50% entre los valores M y F, por lo que el costo de ir a recorrer la segunda parte del índice será mayor que el de ir seleccionando las filas devueltas por la primera columna. La cosa variaría si hubiese muy pocas filas con el valor 'M'. En ese caso podría hasta convenir escoger dicha columna en primer lugar.



  • IMPORTANTE: Como comenté antes, esta sección está pensado para alumnos que van a desarrollar aplicaciones y que existen otras personas que se encargan de optimizar la base de datos (los administradores).
Si se quiere profundizar en esta parcela, puedes consultar este enlace de la Wiki.




Eventos

Introducción

  • Los eventos son tareas que se ejecutan en base a un horario definido previamente.
  • Antes de la versión 5.7, los eventos eran 'simulados' haciendo uso de la función cron del sistema operativo LINUX o con el programador de tareas de Windows.
  • Un evento se identifica por su nombre. Cada evento está asociado a un esquema (base de datos) y se ejecuta en un intervalo de tiempo determinado.
Un evento ejecuta un conjunto de instrucciones SQL formando un bloque dentro de un BEGIN - END.


  • Los eventos se pueden programar para que se ejecuten una única vez o periódicamente.
  • Si vale OFF: El thread que se encarga de ejecutar los eventos está desactivado y por lo tanto no se ejecutará ningún evento. La tarea 'event_sheduler' no se muestra con la orden SHOW PROCESSLIST. Es el valor por defecto. En este estado, para activar el planificador de eventos debemos darle el valor ON a esta variable.
  • Si vale ON: El 'Event Scheduler' (planificador de eventos) es iniciado. En este caso aparecerá como un proceso más al ejecutar la orden SQL: SHOW PROCESSLIST. Para desactivarlo tendremos que cambiar su valor a OFF.
  • Si vale DISABLED: En este caso el planificador de eventos no podría ser activado dinámicamente cambiando el valor de la variable global a ON.
Nota: Podéis consultar en este enlace de la Wiki como cambiar el valor de una variable global.



Creación de eventos


Mysql Eventos 00.jpg
Imagen obtenida de https://dev.mysql.com


  • Entre las diferentes opciones tenemos:
  • ON SCHEDULE: Indicamos el momento en que se va a ejecutar el evento y su frecuencia (una vez, una vez cada cierto tiempo, entre dos intervalos de tiempo,....)
  • DEFINER: Al igual que en el caso de las vistas y procedimientos, indicamos el usuario con el que se va a ejecutar el evento y por lo tanto se ejecutará con los permisos que tenga asociados dicho usuario.
  • event_body: Es el contenido del evento.
  • ON COMPLETION PRESERVE indica que el evento, cuando se termina de ejecutar (y si ya no va a ejecutarse posteriormente) no se elimine (el comportamiento por defecto es el contrario y se indica con la opción ON COMPLETION NOT PRESERVE).
  • DISABLE indica que el evento está creado pero no se va a ejecutar. Para activarlo (normalmente con la orden SQL ALTER EVENT) pondremos ENABLE. La opción DISABLE ON SLAVE se utiliza en entornos de replicación con Mysql instalado en varios equipos. Lo que indicaría esta opción es que el evento sólo debe ejecutarse en el MASTER y no debe replicarse a los SLAVES.


  • Al igual que los procedimientos, podemos tener varias órdenes en el cuerpo del evento.
En ese caso deberemos poner después del DO BEGIN Código del evento END
Deberemos establecer un delimitador diferente antes del CREATE para separar el fin del CREATE con el fin de cada instrucción SQL que conforma el evento (al igual que pasaba en los procedimientos).


  • Una función que nos puede ser útil
  • CURRENT_TIMESTAMP que nos devuelve el día y hora actual del sistema y que se suele utilizar para establecer los intervalos de ejecución del evento de la forma: EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 30 MINUTE ENDS CURRENT_TIMESTAMP + INTERVAL 4 WEEK (es un ejemplo)
  • Funciones para el manejo de tiempos y fechas.


  • Veamos un ejemplo sobre la base de datos employees (recordar cambiar el valor de la variable del sistema event_scheduler).
Vamos a crear un evento que se ejecute el día uno de cada mes y que obtenga los nombres de los empleados que hayan sido contratados durante el mes anterior.
Dichos nombres de guardarán en una tabla de nombre empleados_mes creada previamente.
delimiter \\

CREATE EVENT empleados_del_mes
    ON SCHEDULE 
        EVERY 1 MONTH
    COMMENT 'Guarda los empleados contratados en el mes anterior'
    DO
    BEGIN

        INSERT INTO empleados_mes (nombre)
        SELECT concat(first_name,' ',last_name) 
        FROM employees.employees
        WHERE hire_date >= DATE_SUB(NOW(), INTERVAL 1 MONTH);
    END\\
    
delimiter ;
Veremos después consultando los datos del evento, que éste no comenzará hasta el mes que viene.



Modificación de eventos


  • Veamos un ejemplo.
Sobre el evento creado en el paso anterior, haz una modificación para que comience en el mes actual:
ALTER EVENT empleados_del_mes
ON SCHEDULE 
EVERY 1 MONTH STARTS NOW();



Borrado de eventos


  • Si intentamos borrar un evento que no existe sin utilizar la opción DROP EVENT IF EXISTS el gestor Mysql lanzará una excepción con el mensaje: ERROR 1517 (HY000): Unknown event 'event_name'
  • Veamos un ejemplo:
DROP EVENT [IF EXISTS] nombre_del_evento;



Consulta de eventos

  • La orden SQL que permite obtener información de un evento es SHOW EVENTS.
Se necesita el privilegio EVENT sobre la base de datos.
Para ver los eventos asociados a una base de datos específica podemos hacer uso de la palabra FROM de la forma: SHOW EVENTS FROM nombre_bd;
También podemos 'buscar' como ya hicimos anteriormente:
  • Si queremos buscar por los eventos por su nombre podemos hacer uso de la cláusula LIKE que busca por patrón (símbolo comodín el %) nombres de eventos.
  • Si queremos buscar dentro de los resultados aquellas filas que cumplan alguna condición asociada al valor de alguna columna debemos hacer uso la cláusula WHERE. Por ejemplo: SHOW EVENTS WHERE Definer like 'root%'
Veamos un ejemplo:
SHOW EVENTS;
La orden anterior muestra información sobre quien creó el evento, cuando comienza a ejecutarse y su intervalo de ejecución, cuando finaliza, si está habilitado y sobre qué base de datos actúa.
Mysql eventos 1.jpg


  • Si queremos obtener el código del evento, debemos de ejecutar la orden SQL SHOW CREATE EVENT.
También podemos consultar directamente el diccionario de datos, concretamente la tabla EVENTS de la base de datos INFORMATION_SCHEMA.
Veamos un ejemplo:
SHOW CREATE EVENT empleados_del_mes;


Mysql eventos 2.jpg



  • IMPORTANTE: Para obtener información sobre cómo fue la ejecución de un evento debemos consultar al fichero de log (por defecto es /var/log/mysql/error.log):
cat /var/log/mysql/error.log | grep Event


Mysql eventos 3.jpg



Ejercicios propuestos

  • Nota: Para crear una tabla podemos hacer uso de la orden SQL: CREATE TABLE nombre_table SELECT col1,col2,... FROM tabla (o de una tabla temporal con la orden CREATE TEMPORARY TABLE)
Lógicamente si la tabla existe dará un error, por lo que deberíamos borrarla previamente en caso de que exista: DROP TABLE IF EXISTS nombre_tabla;
Si quisiéramos añadir filas una vez creada, en vez de hacer el drop en caso de que exista, tendríamos que hacer un insert multifila:
  • Comprobamos si existe: SELECT count(*) FROM information_schema.TABLES WHERE (TABLE_SCHEMA = 'BASE_DE_DATOS') AND (TABLE_NAME = 'TABLA_A_BUSCAR');
  • Insert multifila: INSERT INTO tabla_destino (col_tabla_destino) SELECT col FROM tabla_origen;


  • Queremos registrar, cada 1 minuto en el día de hoy y durante unos 10 minutos desde el momento de creación del evento, qué usuarios están accediendo a la base de datos employees. Estos usuarios (sus nombres y equipos) deberán quedar registrados en una tabla de nombre 'historico_usuarios_hora' en la que se guardará el nombre del usuario así como el día-hora-minuto en el que se produjo el registro de actividad.
Crea dos usuarios y conéctate a la base de de datos. Después haz que uno de ellos se desconecte la base de datos.
Modifica el evento y haz que el evento no desaparezca cuando termine el intervalo de ejecución.
Modifica el evento para que se vuelva a ejecutar en el minuto siguiente al actual y comprueba que registra nuevamente a uno de los usuarios anteriores (que se vuelva a conectar)
Pista: La tabla del diccionario de datos donde se guarda esta información es information_schema.processlist y disponéis de un ejemplo de uso en este enlace.


  • Haz que el día 30 de Abril del 2018 a las 23:15 se guarde una copia de los datos de la tabla departments en una tabla creada por ti previamente de nombre dept_copia_temp


  • Crea una table de nombre empleados_numero_mensual que guarde el número de empleados que tiene la empresa. Haz que se ejecute una vez 4 días después de que se cree el evento.
Ejecuta la orden que muestre el momento en que se va a ejecutar.
Modifica el evento para que se ejecute desde el día de hoy hasta dentro de un año y que lo haga cada mes.
Ejecuta la orden que muestre el momento en que se va a ejecutar.


  • Haz que el día 1 de Enero de cada año se actualicen los salarios de los manager de cada departamento un 10% (trabajan mucho :) que estén trabajando actualmente en la empresa). Esta actualización se debe producir durante 5 años a partir del actual.
Cambia la hora del sistema para comprobar que se ejecuta el evento.


  • Muestra todos los eventos creados de la base de datos employees.
Muestra todos los eventos creados de la base de datos employees y que fueran creados por el usuario root.


  • Borra uno de los eventos, asegurándote de que exista.


  • Crea un evento que se ejecute cada día a las 22:00 y que pase a un archivo .csv el contenido de la tabla departments, con el nombre departments_datos.csv
Para hacerlo puedes hacer uso de una tabla con motor CSV o bien haciendo uso de la orden SQL SELECT INTO
En el enlace anterior podemos ver un ejemplo de uso:
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM test_table;
Nota: En la versión actual el único directorio por defecto al que se puede escribir con la orden anterior es /var/lib/mysql-files/
Si se quiere escribir en otro lugar del disco habría que modificar la variable del sistema secure_file_priv.




Usuarios y privilegios

  • Nota Informativa: Recordar que este curso está orientado a alumnos de programación. Si se quiere tener una idea más profunda sobre usuarios y permisos pero orientado a la administración, visitar esta sección del curso de Mysql 5.7 de esta Wiki.



Niveles de seguridad

  • Parece lógico que si queremos acceder a información guardada en una base de datos, tengamos establecido algún sistema de permisos que especifique que operaciones van a poderse realizar con los datos guardados.
Además, el servidor Mysql también va a permitir gestionar ciertos permisos administrativos sobre el propio gestor.


  • Las operaciones que vamos a poder realizar las podemos agrupar en las siguientes categorías:
  • DATOS (conformaría el Lenguaje de Manipulación de Datos => DML (Data Manipulation Language), componente de un Sistema de Gestión de Base de Datos):
  • Manipulación de datos: INSERT, UPDATE, DELETE aplicadas a tablas/vistas dentro de una base de datos.
  • Consulta de datos: SELECT aplicada a tablas/vistas dentro de una base de datos.
  • Vistas: CREATE VIEW, ALTER VIEW, DROP VIEW.
  • Resto de órdenes DML.
  • GESTIÓN (conformaría el Lenguaje de Definición de Datos => DDL (Data Definition Language), componente de un Sistema de Gestión de Base de Datos):
  • Base de datos: CREATE DATABASE, ALTER DATABASE, DROP DATABASE
  • Tablas: CREATE TABLE, ALTER TABLE, DROP TABLE
  • Procedimientos almacenados: CREATE PROCEDURE, ALTER PROCEDURE, DROP PROCEDURE, EXECUTE
  • Triggers: CREATE TRIGGER, ALTER TRIGGER, DROP TRIGGER
  • Resto de órdenes DDL.
  • SEGURIDAD (conformaría un sub-lenguaje del Lenguaje de Definición de Datos, denominado Lenguaje de Control de Datos (Data Control Language => DCL)):


  • Mysql incorpora un sistema de seguridad en el que con las órdenes definidas en el DCL, especifica qué permisos DDL y DML va a tener un usuario.
  • Para ello debemos pasar por diferentes niveles de seguridad.

Primer Nivel: Mysql

  • El primer nivel lo compone el propio Mysql.
Debemos de determinar qué usuarios tienen permiso de conexión al servidor Mysql.
  • La información que va a guardar Mysql para determinar si un usuario tiene permiso de conexión es:
  • Nombre del usuario
  • Password del usuario
  • Dirección IP/Nombre del host desde el que el usuario está intentando conectarse al servidor.
  • Toda esa información está guardada en la tabla user de la base de datos mysql.
  • Si ejecutamos la orden SQL: desc mysql.user podemos observar lo siguiente:
Mysql seguridad 1.jpg
  • Host: Indica la dirección ip/nombre del host desde el cual el usuario va a poder conectarse.
Recordar que por defecto, Mysql no permite conexiones remotas utilizando TCP/IP, por lo que tendríais que comentar la bind-address variable del sistema bind-address] en su archivo de configuración.
Los valores más comunes para este campo suelen ser:
  • localhost/127.0.0.1: esto implica que el usuario sólo puede conectarse vía ssh o estando físicamente en la misma máquina donde se encuentra el servidor Mysql.
  •  %: Cualquier dirección IP.
  • A.B.C.D: Una dirección ip concreta. Por ejemplo: 192.168.1.10
  • Es posible utilizar el símbolo '%' como cualquier parte de una dirección ip de la forma: 192.168.1.%
  • Es posible utilizar el símbolo '%' como cualquier parte de un nombre de host de la forma: '%.mysql.com'
Más información en este enlace.
  • User: El nombre del usuario que tiene acceso al servidor.
  • Password: El password del usuario. Está encriptada.


  • Importante: Recordar que los usuarios del servidor Mysql no tienen nada que ver con los usuarios creados a nivel del sistema operativo.


  • Una vez creado un usuario, éste puede conectarse al Mysql, pero no puede realizar ninguna acción ya que no tiene establecido ningún tipo de permiso.



Mysql seguridad 6.jpg
Imagen obtenida de este enlace


  • Podemos observar como hay permisos que se sitúan a este nivel (al nivel de Mysql) y no continúan por el resto de niveles de seguridad.
Son permisos que afectan al servidor Mysql y no a sus objetos (bases de datos, tablas,...).
Por ejemplo, el permiso para poder parar el servicio de Mysql está en la columna shutdown_priv. Si un usuario tiene este permiso el gestor Mysql ya no necesita consultar ninguna otra tabla.



Segundo Nivel: Bases de datos

  • Una vez creado el usuario debemos otorgarle permisos.
Los más comunes son los que le van a permitir realizar operaciones sobre una base de datos.
  • Cuando creamos un usuario podemos otorgarle permisos a nivel de 'todas las bases de datos' o a nivel de 'una base de datos en particular'.


  • Los permisos globales (los que se aplican a todas las bases de datos) están definidos en la propia tabla 'user' de la base de datos 'mysql'.
Mysql seguridad 2.jpg
En la imagen podemos observar las columnas de la tabla user: 'select_priv','update_priv','delete_priv','insert_priv'.
Estas columnas son de tipo ENUM y sólo pueden tener un valor 'Y' o 'N' y por defecto, el valor predeterminado es 'NO'. Un usuario que tenga puesto a 'YES' el valor de estas columnas, tendría como consecuencia que podría realizar operaciones SQL de SELECT, UPDATE, DELETE e INSERT sobre todas las tablas de todas las bases de datos de Mysql.
  • Los permisos locales a nivel de una base de datos en particular se encuentran guardados en la tabla db de la base de datos mysql.
En el caso de que un usuario intentara realizar alguna operación en una base de datos, y no tuviera permiso 'global' para realizarla, iría a esta tabla a buscar si tiene otorgado el permiso.
Mysql seguridad 4.jpg
Si vemos la imagen podemos comprobar como en esta tabla:
  • Las columnas Host,Db, User conforman la clave primaria de la tabla y por tanto no puede haber dos filas con los mismos valores.
  • Host: nombre del host desde está permitido acceder a la base de datos.
  • Db: nombre de la base de datos.
  • User: nombre del usuario que tiene permiso de acceso a la base de datos.
  • Igual que en los permisos a nivel global, un permiso a 'YES' en esta tabla, implicaría que el usuario tendría ese permiso en todas las tablas creadas dentro de la base de datos.


Mysql seguridad 5.jpg
Podemos comprobar en la imagen superior como el usuario 'user1' tiene permiso de selección (select_priv) desde 'localhost' en la base de datos 'employees' y por lo tanto va a poder ejecutar la orden SQL SELECT sobre cualquier tabla de la base de datos.


Mysql seguridad 7.jpg
Imagen obtenida de este enlace



Tercer Nivel: Tablas y columnas

  • A nivel de tabla, un usuario que tenga permiso a este nivel lo tendrá sobre toda la tabla.
Es decir, si tengo permiso de selección, podré seleccionar todas las columnas de la tabla.
Los permisos en este nivel se guardan en la tabla tables_priv de la base de datos mysql.
Mysql seguridad 8.jpg
Como observamos, las columnas de la tabla tienen:
  • Clave primaria formada por las columnas (User,Db,Host y Table_name).
  • Grantor: Indica el usuario que otorgó este permiso.
  • TimeStamp: El momento en que se otorgó el permiso.
  • TablePriv: Tabla sobre la que se va a aplicar el permiso.
Debemos de tener en cuenta que si otorgamos permiso a nivel de tabla, aquí aparecerá el tipo de permiso (por ejemplo, delete,insert).
Es de tipo SET y a diferencia de los de tipo 'ENUM' pueden tener varios valores, dentro de las opciones posibles,
  • Column_priv: En caso de que tengamos un permiso a nivel de tabla, esta columna estará en blanco. Si tenemos un permiso a nivel de columna, esta columna tendré el tipo de permiso (por ejemplo, update) y la columna anterior (TablePriv) estará en blanco (podría tener un permiso diferente al de update).
Es de tipo SET y a diferencia de los de tipo 'ENUM' pueden tener varios valores, dentro de las opciones posibles,


Mysql seguridad 12.jpg
Imagen obtenida deeste enlace



  • El listado de los posibles permisos que podemos otorgar a nivel de tabla/columna se muestran en la siguiente imagen (también están los permisos a nivel de proc. y funciones que se comenta en el siguiente punto).
Mysql seguridad 19.jpg
Imagen obtenida de este enlace

Procedimientos y funciones

  • Son permisos que afectan a los procedimientos y funciones que podamos tener creados en Mysql.
Uno de los permisos que vamos a tener es el de ejecución (EXECUTE) para que un usuario pueda llamar al procedimiento/función.
Mysql seguridad 13.jpg
  • Las columnas TimeStamp y Grantor no se utilizan.


Mysql seguridad 14.jpg
Imagen obtenida de este enlace


  • Los permisos que podemos otorgar a este nivel son los indicados en la siguiente figura en la última fila (proc_priv):
Mysql seguridad 19.jpg


Como podemos ver, los permisos que podemos aplicar a nivel de un procedimiento/función concreto son los de poder ejecutarlo (EXECUTE), poder modificarlo o borrarlo (ALTER ROUTINE) y que tengamos el permiso para poder otorgar los dos permisos anteriores a otros usuarios (GRANT). Estos permisos se registran en la tabla mysql.provs_priv.
Disponemos de los mismos permisos en los otros niveles vistos anteriormente, a nivel general (mysql.user) y a nivel de base de datos concreta (mysql.db). En estos niveles, a mayores disponemos del permiso CREATE ROUTINE que permite a un usuario que tenga dicho permiso crear procedimientos/funciones.



Creación de Usuarios


SQL

Añadiendo usuarios
  • La orden SQL que permite añadir nuevos usuarios es: CREATE USER.


Mysql usuarios 13.jpg
Imagen obtenida de este enlace


Su forma más simple:
CREATE USER nombre_usuario IDENTIFIED BY 'password';
nombre_usuario tiene el formato: 'usuario'@'host'
Por ejemplo:
CREATE USER 'angel'@'localhost' IDENTIFIED BY '12345678';
Estaríamos añadiendo una nueva fila a la tabla 'user' de la base de datos 'mysql', con nombre de usuario 'angel' y password '12345678'


  • Si no podemos la palabra clave 'IDENTIFIED BY' estaríamos creando un usuario sin contraseña, lo cual no es recomendado.
Por ejemplo:
CREATE USER 'anonimo'@'localhost';
Al crear este usuario sin contraseña, podríamos conectarnos al Mysql sin enviar el parámetro -p o --password en herramientas clientes:
mysql -u anonimo


  • Si no indicamos el host, Mysql asignará el patrón '%' al mismo.
Por ejemplo:
CREATE USER 'anonimo';


  • Nota: Es importante tener en cuenta el formato del usuario de la forma: 'usuario'@'host', ya que si ponemos esto: 'usuario@host' estaríamos creando un usuario de nombre 'usuario@host' que puede conectarse desde cualquier PC.


  • Para ver las sentencia 'CREATE USER' utilizada para crear un determinado usuario, debemos ejecutar la orden SQL: SHOW CREATE USER usuario
Por ejemplo, para ver la sentencia 'create user' del usuario actual podemos poner:
SHOW CREATE USER CURRENT_USER();
Mysql usuarios 1.jpg





Opciones para el password
Mysql usuarios 14.jpg


  • Podemos 'obligar' a que un usuario cambie su contraseña cuando se conecta por primera vez:
1 CREATE USER 'angel'@'localhost' IDENTIFIED BY '12345678' PASSWORD EXPIRE;
Poniendo la palabra 'PASSWORD EXPIRE'.
  • También podemos 'obligar' al usuario a que cambie de password cada cierto número de días:
1 CREATE USER 'angel'@'localhost' IDENTIFIED BY '12345678' PASSWORD EXPIRE INTERVAL 60 DAY;
En el ejemplo, deberá cambiar de password cada 60 días.
  • El resto de opciones indicarían:
  • NEVER: que el password nunca 'caduca'.
  • DEFAULT: El password caducaría en el número de días indicado por la variable del sistema default_password_lifetime que es de 360 días en versiones anteriores a la 5.7.11 y 0 (no caduca) a partir de la versión anterior.




Bloqueo / Desbloqueo de cuentas
Mysql usuarios 15.jpg


  • Cuando creamos (o modificamos) una cuenta, podemos indicar si dicha cuenta está bloqueada.
En caso de estarlo, no estaría permitida la conexión al servidor Mysql haciendo uso de dicha cuenta.
Es una características que aparece a partir de la versión 5.7 de Mysql.


  • Por ejemplo:
1 CREATE USER 'angel'@'localhost' IDENTIFIED BY '12345678' ACCOUNT LOCK;
Por defecto las cuentas, si no indicamos nada, son creadas con el estado desbloqueado, sería lo mismo que poner:
1 CREATE USER 'angel'@'localhost' IDENTIFIED BY '12345678' ACCOUNT UNLOCK;


  • Para saber si una cuenta está bloqueada podemos hacer uso de la orden SQL: SHOW CREATE USER usuario.
Mysql usuarios 16.jpg



Modificando usuarios
  • La orden SQL que permite modificar usuarios es: ALTER USER.


Mysql usuarios 22.jpg
Imagen obtenida de este enlace


  • Como vemos la sintaxis es casi idéntica a la del CREATE USER, con las mismas opciones, lo que pasa es que estaríamos modificando los valores de dichas opciones para un usuario existente.
  • Lo único diferente es la opción IF EXISTS. Dicha opción sirve para que el gestor Mysql realice la orden SQL 'ALTER USER' sólo en el caso de que el usuario exista. Si no existe no hace nada.
Si no ponemos esta opción a la hora de modificar un usuario, tendríamos un mensaje de error.
Si estamos ejecutando un conjunto de instrucciones Mysql, pararía al llegar a esta instrucción.


  • Un ejemplo:
ALTER USER IF EXISTS 'angel'@'%' IDENTIFIED BY 'nueva_password';


  • Para modificar el nombre del usuario debemos hacer uso de la orden SQL: RENAME USER.
Mysql usuarios 46.jpg


  • Un ejemplo:
RENAME USER 'angel'@'%' to 'angel2'@'localhost';



Borrando usuarios
  • La orden SQL que permite dar de baja a usuarios es: DROP USER.


Mysql usuarios 23.jpg
Imagen obtenida de este enlace
  • Un ejemplo:
DROP USER IF EXISTS 'angel'@'%';




WorkBench=

  • Podemos dar de alta, modificar o dar de baja a los usuarios desde la herramienta cliente MysqlWorkBench.


  • Las operaciones de baja y modificación son bastantes obvias de ver.
  • Para modificar sólo debemos de seleccionar el usuario, hacer los cambios que queramos, y pulsar el botón Apply.
  • Para borrar un usuario sólo debemos de seleccionar el usuario y pulsar el botón Delete.




PhpMyAdmin

Podemos dar de alta, modificar o dar de baja a los usuarios desde la herramienta cliente web PhpMyadmin.


  • Para dar de alta a un nuevo usuario:



  • Para eliminar uno o más usuarios debemos escogerlos pulsando en el checkbox al lado de su nombre y pulsar el botón Continuar.
En el caso de que tuvieran bases de datos con el mismo nombre que el nombre del usuario, podríamos eliminarlas si seleccionamos el checkbox 'Eliminar las bases de datos que tienen....'
Mysql usuarios 40.jpg



  • Para modificar un usuario debemos de escoger la opción Editar Privilegios:




Ejercicios propuestos

SQL

  • Crea tres usuarios de nombre u1,u2,u3 utilizando una única instrucción SQL. Todos se van a conectar desde la red 170.10.0.0/16.
Haz que tengan que cambiar la contraseña cuando se conecten, y que como máximo puedan realizar 50 operaciones de modificación por hora contra la base de datos.
Sólo podrán conectarse desde un computador simultáneamente.


  • Haz que cualquier usuario que se cree, pueda por defecto, realizar como máximo 3 conexiones simultaneas al servidor.
Crea un usuario y comprueba que esto es cierto. Visualiza el valor de la variable del sistema que afecta al usuario (a nivel de sesión)
  • Crea dos usuarios utilizando una única orden SQL, de tal forma que las dos cuentas estén inicialmente bloqueadas y que el máximo número de conexiones simultáneas sea de 1.
Debes obligar a que dichos usuarios utilicen conexiones seguras.


  • Desbloquea las cuentas anteriores.


  • Modifica los usuarios u1 y u2 utilizando una única instrucción SQL y elimina la restricción de que el número máximo de operaciones sea de cincuenta, pero ponles la limitación de que el máximo número de consultas sea de cien a la hora.


  • Modifica el password del usuario u3 y desbloquéalo en una única instrucción SQL


  • Da de baja al usuario u1.



PhpMyadmin

  • Crea un usuario de nombre work1 y dale permiso total sobre cualquier base de datos de nombre work1_???????
  • Modifica el usuario creado en el paso anterior y limita el número máximo de conexiones por hora a 10 y que la conexión con el servidor sea segura.
  • Crea un usuario con una base de datos con su mismo nombre y que tenga permiso sobre ella para hacer cualquier operación.
  • Crea un nuevo usuario y elimina el anterior en una misma operación.



MysqlWorkBench

  • Crea un usuario de nombre work2 que se pueda conectar desde cualquier red con ip 10.1.1.X.
  • Modifica el usuario anterior e impide que pueda hacer más de 10 operaciones de modificación a la hora.
  • Modifica el usuario anterior y oblígalo a que se conecte con conexiones seguras. ¿ Como comprobarías desde workbench que la conexión es segura ?
  • Crea una conexión desde tu equipo real al virtualizado utilizando un túnel ssh, haciendo que en tu equipo (el real) una conexión al puerto 4000 se redirija al puerto 3306 del servidor mysql.
Crea un usuario en Mysql que tenga permiso de acceso. Desde qué ip ? (la pregunta tiene trampa)
Crea una conexión en MysqlWorkbench conectándote con este usuario.

Copias de seguridad


Importación/Exportación







Enlace a la página principal de la UD8

Enlace a la página principal del curso




-- Ángel D. Fernández González -- (2020).