-ACTIVIDAD PUNTUABLE 4 (CORRESPONDIENTE AL TEMA 5)

1. TÍTULO DE LA ACTIVIDAD: Optimización y monitorización

2. DESCRIPCIÓN DE LA ACTIVIDAD:

OBJETIVOSEn esta actividad práctica vas a utilizar los elementos y herramientas de un SGBD como MySQL para optimizar el funcionamiento de una base de datos, y hacer que las operaciones de consulta sobre ella sean lo más rápidas posible. También vas a aprender a utilizar pautas básicas para optimizar las consultas, para obtener las consultas más eficientes de las distintas posibles.En la última parte vas a utilizar herramientas para monitorizar y optimizar el funcionamiento del servidor de MySQL.

METODOLOGÍA- La mejor manera de alcanzar los objetivos de este tema para hacer los ejercicios es hacer previamente los ejemplos del manual, para ver los resultados que se van comentando. Teniendo en cuenta que las bases de datos que utiliza el libro en la mayoría de los ejemplos, parten de la base de que las tablas no tienen los índices. Mientras que en realidad éstos están creados ya al introducir estas bases de datos por medio del script adjunto.- Es importante entender de forma razonada las recomendaciones sobre optimización que hace el capítulo y no aplicarlas directamente sin ningún sentido.-Para cualquier problema o duda sobre la sintaxis de un ejemplo o cómo utilizar cualquiera de las herramientas que se ven en el capítulo se recomienda consultar la documentación oficial (http://www.mysql.com), además del manual de la asignatura, antes que buscar en cualquier foro o blog no oficial.

ACTIVIDADi. Sobre la base de datos “nmotor” consulta la información de los

índices de la tabla “noticias". Escribe cómo se llaman los índices encontrados, los campos sobre los que están creados y el tipo de índices. Comenta por qué crees que son útiles para esa tabla los esos índices.

Comando para mostrar la información de los índices de una tabla:show index from noticias;

Los índices encontrados de la tabla noticias son lo que se muestran en la imagen de arriba:

El nombre del primer índice es in1 y el segundo es full, aunque aparecen 3 registros el índice

full es el mismo ya que es un índice combinado o compuesto ya que esta compuesto por dos

campos de la tabla.El primero índice in1 esta creado solo sobre el campo de la tabla id y es un tipo de índice es Parciales: El interés de un índice parcial reside en la ganancia de velocidad. Un índice corto es mucho más rápido. Y podemos suponer que los 10 primeros caracteres del nombre son lo suficiente representativos.Y la Estructura del índice es BTREE: Índice con estructura de árbol, muy utilizado por su flexibilidad,rendimiento y ahorro de espacio. Además de agilizar las consultas directaspor los campos indexados, también agilizan las consultas por rango (BETWEEN) y por comparadores (<, >, >=, <=). MySQL utiliza índices B-Tree en los motores MyISAM e InnoDB. En el caso de InnoDB, el índice está “incrustado”, es decir, que se almacena junto a los datos (y no en un fichero separado como en MyISAM).

El segundo índice full esta creado sobre los dos campos de la tabla titulo y contenido y es de tipo Multicolumna: El valor del índice se obtiene concatenando los valores de los diferentes campos que componen el índice. MySQL solo permite un índice por tabla y consulta.

Y la estructura del índice es FULLTEXT: formados por uno o varios de texto y utilizados para la búsqueda de palabras dentro de un campo (típicamente para campos de gran tamaño) en funciones de búsqueda de cadenas (full-text search), solo para tablas de tipo MyISAN y en campos de tipo CHAR, VARCHAR y TEXT. Este tipo de búsquedas se realizan con el comando SQL MATCH… AGAINST cuya sinteasis es:MATCH (colo1,col2………..) AGAINST (expr [search_modifier]).

ii. Sobre la base de datos “nmotor” comprueba que uno de los índices de la tabla “noticias” es de tipo FULLTEXT. ¿Sobre qué campos está creado este índice denominado “full”? ¿Para qué sirve este tipo de índices? Escribe las sentencias necesarias para eliminarlo y volverlo a crear como estaba (haz esta última parte de dos maneras diferentes: con CREATE INDEX… Y CON ALTER TABLE…)

Como se ve en la imagen en azul es el índice FULLTEXT. Mencionado en el

apartado anterior.

Este tipo de índices se usan para:

FULLTEXT: formados por uno o varios de texto y utilizados para la búsqueda de

palabras dentro de un campo (típicamente para campos de gran tamaño) en

funciones de búsqueda de cadenas (full-text search), solo para tablas de tipo

MyISAN y en campos de tipo CHAR, VARCHAR y TEXT. Este tipo de búsquedas

se realizan con el comando SQL MATCH… AGAINST cuya sintasis es:

MATCH (colo1,col2………..) AGAINST (expr [search_modifier]).

Comando para borrar el indice:

drop index full on noticias;

Y como se ve en la imagen de abajo el indice ha sido borrado:

Comando para la creaccion del indice con CREATE:

CREATE fulltext index full on noticias(titulo,contenido);

Comando para la creaccion del indice con ALTER TABLE:

ALTER TABLE noticias add fulltext index full (titulo,contenido);

iii. Sobre la base de datos “nmotor”, utiliza el comando EXPLAIN para ver cómo se realizará la siguiente consulta:

select * from noticias where id between 1 and 500;¿Cuántas filas se estima que será necesario recorrer para esta consulta? ¿Con qué posibles índices se hará? ¿De qué tipo es esta consulta?Ahora compara los resultados de hacer la misma consulta pero utilizando el parámetro IGNORE INDEX para evitar que se utilicen todos los índices, o eliminando los índices creados sobre la tabla noticias.

COMANDO CON EXPLAIN:EXPLAIN select * from noticias where id between 1 and 500;

Estima recorrer 118 filas que lo indica en el campo rows.

El posible índice que utilizara en in1, lo indica en el campo possible_Keys.

El tipo de consulta se indica en los campos select_type que toma en valor SIMPLE (para

consultas que no sean uniones o incluyan subconsultas) y en el campo type que toma el valor

range (Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para

seleccionar las filas. La columna key indica cual índice es usado, y el valor key_len contiene la

parte más grande de la clave que fue usada. La columna ref será NULL para este tipo.).

COMANDO CON IGNORE INDEX:EXPLAIN select * from noticias IGNORE INDEX (in1) where id between 1 and 500;

Como se ve en la imagen al ignorar el indice la consulta es mucho mas costosa:

Se recorren 3337 filas indicado en el campo rows.

No se usua nigun indide ya que aparecen los campos en NULL.

El tipo de consulta se indica en los campos select_type que toma en valor SIMPLE (para

consultas que no sean uniones o incluyan subconsultas) es la misma que en la sentencia

anterior, pero en el campo type ahora en valor es ALL que indica que realiza Un escaneo

completo de tabla será hecho por cada combinación de filas de las tablas previas. Este es

normalmente no bueno si la tabla es la primera no marcada const, y usualmente muy malo en

todos los otros casos.

Por lo tanto al ignorar los índices la consulta es bastante mas costosa ya que debe recorres

todos los campos de la tabla, para poder mostrar los valores resultante de la consulta unos

3337, que comparado con el valor anterior de 118 es bastante superior y costoso.

Comparacion de tiempo de las dos consultas una con índice la primera y la otra sin el índice,

que se muestra en la siguiente imagen:

El tiempo es la segunda consulta es mas de doble.

iv. Explica cómo optimizarías la siguiente sentencia, sobre la base de datos “liga”.

select count(*), equipo from jugador group by equipo;

explain select count(*), equipo from jugador group by equipo;

En el comando con EXPLAIN, en el campo extra salen dos valores Using temporary que indica

que se usaran tablas temporales para la ordenación y almacenamiento del resultado de la

búsqueda, y el valor Using filesort que indica que dichos valores o resultado necesita

ordenación. Tambien nos indica en el campo type ALL que es la consulta mas mala posible ya

que debe de recorrer todos los valores de la tabla.

Para optimizar esta consulta, los campos a ordenar debe ser todos ellos de un índice y la

ordenación debe ser en el mismo orden. Por eso se hace la ordenación en función de un solo

campo. Al ser una consulta con GROUP BY lo mejor es crear el índice invirtiendo el orden de los

campos para evitar el filesort y crearíamos el índice de la siguiente manera, y come se ve al

crear el índice invertimos el orden de los campos en el comando “(equipo,id_jugador)”;

create index myorden on jugador (equipo,id_jugador);

Vemos como se ha creado el índice:

Y ahora veremos el resultado del comando explain con la misma consulta pero ahora con el

uso del índice creado:

Como se ve ya en el campo extra ya no aparece el filesort, e indica que se usa índices y el

índice usado es el creado por nosotros, y ya en el campo type ya no aparece el valor ALL(el

pero posible) si el valor index que indica que va al índice al realizar la consulta y es de donde

toma los valores y da el resultado de la consulta, por lo que el tiempo de la operación se

reduce considerablemente.

Comparacion de tiempo de respuesta con índice y sin índice (es mas veloz con índice):

v. Indica los comandos necesarios para:

a. Ver las variables globales y de sesión y el estado de las operaciones “update”Variables globales:show global variables like "%update%";

Variables de sesión:

Show session variables like "%update%";

Variables de estado (status):

Show status like "%update%";

b. Ver las variables el estado relacionado con tablas abiertas y creadas.Show global status like "%tables%";

c. El estado del motor de almacenamiento InnoDB.Show engine innodb status;

d. Mostrar todas las bases de estado existentes en nuestro servidor Show databases;

e. Mostrar todas las tablas de una base de datos.Use nombre_BBDD;Show tables;

f. Mostrar todos los usuarios conectados a nuestro servidor y en qué estado se encuentranShow processlist;

3. EXTENSIÓN MÁXIMA DE LA ACTIVIDAD: 10 hojas con las contestaciones y capturas de pantalla solicitadas.