TEMA 9. OPTIMIZACIÓN DEL
RENDIMIENTO DE UNA BBDD
1.
Introducción
Tanto el número de usuarios simultáneos como la cantidad de información a gestionar tienen un impacto importante en el rendimiento del servidor de base de datos. Por este motivo no es raro que, con el uso, el rendimiento de una aplicación decaiga.
El problema no es que MySQL no pueda gestionar eficazmente un gran número de usuarios concurrentes ni grandes bases de datos. El problema está en que las aplicaciones no fueron inicialmente diseñadas para la carga que han de soportar tras varios años de funcionamiento y, sólo entonces, aparecen los problemas de un diseño inicial poco ambicioso o poco previsor.
Una de las tareas principales del Administrador de la BBDD, una vez finalizadas las tareas de implantación del SGBD y una vez que éste se encuentra en fase de explotación, es realizar el seguimiento del servidor y del SGBD, para comprobar su correcto funcionamiento.
MySQL puede gestionar, de forma eficaz, un gran número de usuarios concurrentes y grandes bases de datos. Pero es necesario conocer las características que influyen en el rendimiento de nuestro servidor. Aunque no es posible ni recomendable
1.
Introducción
2.
Mejorar el modelo de datos y la estructura de las tablas
3.
Mejorar las consultas
3.1.
La caché de consultas
3.2.
Análisis
3.3.
Planificación
3.4.
Ejecución
monitorizar la BD constantemente, es preciso hacerlo regularmente y de la forma más automatizada posible.
Los SGBD cuentan con herramientas que ayudan en la tarea de monitorizar el sistema. La herramienta más conveniente será la menos intrusiva, es decir, la que menos interfiera en el sistema y nos pueda proporcionar la medida más fiable del objeto de nuestra observación.
Conviene recordar que todas las herramientas que sean de tipo gráfico consumirán más recursos del sistema y de la base de datos. No debemos olvidar que observar conlleva un consumo de recursos, luego si pretendemos controlar el rendimiento no es lógico hacerlo en un momento en el que la BD está realizando consultas pesadas.
Podemos mejorar el rendimiento del sistema mediante los siguientes métodos: Mejorar el modelo de datos y la estructura de las tablas.
Mejorar las consultas.
Mejorar la configuración del servidor MySQL
2.
Mejorar el modelo de datos y la estructura de las tablas
Las características, número y relaciones de las tablas de nuestra base de datos influyen sustancialmente en el rendimiento de esta. El modelo de datos es además difícilmente modificable una vez desarrollada la aplicación y puesta en producción. No podremos entonces realizar cambios de importancia en el diseño de nuestras tablas porque esto nos obligaría no solo a complejos procesos de migración de datos, sino también a modificar el código de nuestra aplicación. Incluso es posible que sobre el mismo modelo de datos hayamos desarrollado nuevas aplicaciones que también deberían ser cambiadas. Por lo tanto, debemos diseñar cuidadosamente el modelo de datos, teniendo en cuenta que los errores que cometamos nos acompañarnos en el futuro y limitarán el rendimiento de nuestra aplicación.
Para optimizar el modelo de datos debemos trabajar sobre dos aspectos: la elección de los motores de almacenamiento y la normalización.
Debemos tener en cuenta que MySQL permite el uso de varios motores de almacenamiento en una misma base de datos. Incluso es posible combinar motores de almacenamiento distintos en una misma transacción SQL y en una misma consulta. Así que no tenemos que restringirnos al uso de uno sólo de ellos en nuestro modelo de datos. Debemos elegir la combinación más adecuada eligiendo un motor de almacenamiento para cada una de las tablas de nuestro modelo.
Para elegir el motor de almacenamiento más adecuado debemos tener en cuenta las consultas que ejecutaremos sobre él.
El motor MyISAM es el más adecuado cuando la velocidad de respuesta es el factor crítico. Así mismo, serán la mejor opción cuando tengamos que realizar búsquedas textuales o consultas que deban conocer rápidamente el número total de registros de la tabla.
Sin embargo, el motor InnoDB será la elección correcta cuando requiramos soporte para transacciones o integridad referencial.
El resto de motores se utilizan en circunstancias especiales. Pero es preciso conocerlos ya que pueden mejorar notablemente el rendimiento de nuestra base de datos.
El segundo factor de optimización del modelo de datos es la normalización. La normalización es una técnica de diseño de modelos de datos relacionales que estructura paso a paso las tablas para reducir el riesgo de inconsistencias. Existe la creencia de que un modelo de datos es mejor cuanto mayor sea su nivel de normalización. Así, un modelo en tercera forma normal (3FN) sería mejor que otro en segunda forma normal (2FN). Nada más lejos de la realidad.
La calidad de un modelo de datos no depende exclusivamente de su forma normal, sino de su capacidad para responder a las consultas que tendremos que realizar sobre él. El proceso de normalización del modelo de datos elimina las dependencias funcionales entre atributos. Pero, al mismo tiempo, complica el diseño de las consultas y pierde rendimiento.
Pongamos un ejemplo. Supongamos un modelo de datos que recoge información de proyectos y jefes de proyecto asignados a los mismos en la siguiente tabla:
Proyecto
nombre varchar (100) jefe_proyecto varchar (100) telefono varchar (15)
Como puede verse, existe un atributo secundario (teléfono) que no depende de la clave (nombre) sino de otro atributo secundario (jefe_proyecto). El modelo de datos está por lo tanto, en segunda forma normal.
Si lo pasáramos a tercera forma normal, tendríamos que crear dos tablas, una que recogiera los nombres y los jefes de proyecto y otra que recogiera los jefes de proyecto con su teléfono.
Dependiendo de las consultas que se vayan a ejecutar en la base de datos, esta decisión tendría un alto coste en relación al rendimiento de la base de datos. Así, si se realizan con frecuencia consultas en las que aparezcan estos tres campos (nombre, jefe_proyecto y teléfono) es mucho más óptimo diseñar el modelo de datos en 2FN que en 3FN.
Obviamente esto también depende del volumen de datos de la BBDD. No es lo mismo ejecutar esta consulta en una BBDD recién creada, en la que aún no existen muchos datos, que realizarla cuando la BBDD lleva largo tiempo en explotación y, por tanto, tendrá muchos datos.
Respecto a la estructura de las tablas, es necesario tener en cuenta lo siguiente: Las tablas desordenadas provocan una búsqueda secuencial lenta. No obstante,
una tabla ordenada tiene los siguientes inconvenientes: - Ordenar una tabla desordenada es costoso.
- El constante acceso de escritura desordena de nuevo los registros de la tabla.
- La inserción y eliminación ordenada de registros es costosa en términos de rendimiento.
- Cuando ordenamos por una columna desordenamos el resto de columnas. El rendimiento mejora si los registros de la tabla tienen longitud fija (sin campos de tipo VARCHAR, TEXT o BLOB). Si cada campo (columna) tiene una longitud fija entonces cada registro (línea) también tendrá una longitud fija y obtenemos las siguientes ventajas:
- Disminuye la fragmentación: los registros borrados son substituidos por registros de la misma longitud.
- Aumenta la velocidad: los registros son accedidos por "número de registro" en lugar de "desplazamiento dentro del fichero".
- Disminuye el consumo de memoria: el índice es más pequeño.
Podemos desfragmentar tablas para ganar espacio y velocidad con el siguiente comando: OPTIMIZE TABLE tabla.
Las consultas por columnas que pueden contener valores NULL son más lentas.
3.
Mejorar las consultas
Las consultas a la base de datos son el típico punto de degradación de una aplicación tras varios meses o años de funcionamiento. Salvo que nuestra aplicación realice operaciones masivas de inserción de registros, debemos preocuparnos sólo de las operaciones de SELECT. Es en este tipo de operaciones donde notaremos como, poco a poco, se va degradando nuestra aplicación.
La degradación de una consulta que, inicialmente funcionaba bien, se produce por dos motivos. En primer lugar, porque crece el número de registros de nuestra base de datos. Lo habitual es que, al poner la aplicación en marcha tengamos pocos registros (clientes, pedidos, expedientes...) y que, según transcurre el tiempo, las tablas tengan cada vez más registros.
El segundo motivo de degradación es el incremento del número de usuarios, la concurrencia. Al desarrollar la aplicación posiblemente las consultas se probaron con un único usuario. Incluso tras la puesta en marcha suele haber un periodo de aceptación en
el que los usuarios van incorporándose poco a poco a la aplicación, usándola cada día un poco más.
Esta combinación de mayor cantidad de datos y mayor concurrencia puede poner en evidencia un diseño poco profesional de las consultas.
Naturalmente nuestras consultas estarán embebidas en una aplicación, no es habitual que los usuarios lancen consultas SQL directamente a la base de datos. Así que los primeros síntomas de que algo empieza a fallar serán esporádicos. Al principio sólo observaremos que algunas búsquedas van más lentas y fácilmente podremos achacarlo a otras causas. Pero la degradación de las consultas, aunque lenta, es progresiva. Por ello es conveniente, ante la primera sospecha, tratar de poner solución.
Lo primero es detectar el problema, saber qué está pasando ya que puede que en un principio nada nos haga sospechar de la base de datos. Iniciaremos nuestra operación de búsqueda descartando factores... la red, el servidor web, el sistema operativo... hasta llegar a la base de datos.
Cómo medida rápida, podemos utilizar el comando SHOW PROCESSLIST que nos permite visualizar a tiempo real las consultas SQL que se están ejecutando en el servidor. Este comando nos muestra el estado de la consulta, la base de datos, el comando que está ejecutando, el usuario, el host y el tiempo de ejecución, siendo este último de los puntos más importantes para el fin que nos ocupa. Tener en cuenta que para ver el contenido completo de la consulta SQL que se está ejecutando necesitaremos utilizar SHOW FULL PROCESSLIST en lugar del comando anterior.
Para diseñar una estrategia de optimización más elaborada necesitamos utilizar otras herramientas.
Una medida quizás un poco agresiva y que no debería ser ejecutada en servidores de producción es activar el log general (General Query Log) que registrará todas las consultas SQL que se ejecuten en el servidor. Para activarlo debemos especificar la ruta del log mediante la variable global general_log_file, tal y cómo vimos en temas anteriores. Para activarlo utilizaremos la variable general_log que tendrá el valor ON para activado y OFF en caso que queramos desactivarlo.
Una estrategia más eficiente para determinar si la base de datos es el cuello de botella es el log específico de consultas lentas (Slow Query Log). Nos bastará con activar este log durante unos días y analizarlo.
Para ello, tendremos que modificar el fichero de configuración my.conf, de MySQL de la siguiente manera:
log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2
log-queries-not-using-indexes
Con la primera directiva estamos indicando en qué fichero se guardará el log. Con la segunda directiva establecemos el tiempo (en segundos). En este caso, cualquier
consulta que tarde más de 2 segundos en ejecutarse se considerará lenta y será registrada en el log. Y la tercera directiva hará que también se registren en el log las consultas que no utilicen ningún índice para su resolución.
Revisando este log, tras varias horas o días de recogida de información, podremos identificar las consultas lentas de nuestra aplicación. Hay que tener en cuenta que el hecho de que una consulta esté registrada una vez en el log sólo significa que esa vez se ejecutó lentamente. Puede ser que en esa ocasión ocurriera algo en el servidor (un proceso de copia de seguridad, un cliente lento...).
Debemos concentrarnos en las consultas que más se repitan y peores tiempos tengan.
Podemos comprobar qué consultas coinciden con los procesos que los usuarios consideran lentos y, ahora sí, centrarnos en mejorarlas... de una en una.
Para poder mejorar el rendimiento de una consulta debemos conocer antes cómo las resuelve MySQL. Es lo que se conoce como “proceso de consulta”.
Cuando MySQL recibe una consulta, procede de la siguiente forma:
En primer lugar, busca la consulta en la caché. Si hay suerte, ya tendrá los resultados guardados de una consulta anterior y no tendrá que resolverla.
En segundo lugar, si no ha podido utilizar la caché, analiza la consulta, comprueba su sintaxis e identifica su tipo; es la fase de “parseo”.
Con la información obtenida del análisis, llega al siguiente paso, la planificación. Este es el punto crítico y del que dependerá el tiempo de resolución. El planificador de MySQL decide cual será el proceso para resolver la consulta, qué parte se resolverá primero, qué índices se utilizarán y cómo se obtendrán los datos.
Por último, en la fase de ejecución solo resta ejecutar el plan trazado y entregar los resultados al cliente.
Veamos este proceso paso a paso.
3.1
La caché de consultas
MySQL registra las consultas de tipo SELECT y su resultado. Como lo normal es que se acceda a la base de datos a través de una aplicación, las consultas repetidas son muy frecuentes (listas de poblaciones, de códigos, de nombres...).
Si MySQL recibe una consulta que tiene en la caché, simplemente entrega al cliente el mismo conjunto de resultados que produjo en su ejecución anterior. Naturalmente, las consultas de modificación de datos (INSERT, DELETE, UPDATE...)
invalidan las consultas afectadas de la caché y provocan la eliminación de estas de la caché.
Podemos utilizar la caché para mejorar el rendimiento de nuestra base de datos. La variable mysql_cache_type (en my.cnf) establece el tipo de caché que utilizará MySQL.
Un valor a 1 hará que todas las consultas de tipo SELECT sean cacheadas, salvo que expresamente indiquen lo contrario mediante el modificador SQL_NO_CACHE en la sentencia SELECT. Un valor de query_cache_type igual a 2 hará lo contrario. Las consultas no serán cacheadas salvo que expresamente lo soliciten con SQL_CACHE.
De esta forma podremos controlar y mejorar la calidad de la caché, haciendo que las consultas repetidas sean cacheadas y evitando que las consultas que no se repiten (buscadores, datos de un cliente...) consuman espacio de almacenamiento.
El tamaño de la cache se establece en la variable query_cache_size. Y el límite de almacenamiento por consulta en la variable query_cache_limit. La estrategia concreta de uso de estas variables dependerá de las características del servidor y de la aplicación.
3.2
Análisis
En el proceso de análisis (“parseo”), MySQL determina el tipo de consulta, las tablas relacionadas, las características de la cláusula WHERE... pero todo esto apenas tiene incidencia en el rendimiento. Lo único que puedes tener en cuenta es, que cuanto más largas sean las consultas, más tiempo de análisis necesitarán.
3.3
Planificación
El planificador es el punto crítico en la resolución de una consulta. Del plan de ejecución que elabore dependerá que la consulta tarde unas pocas décimas de segundo o varios minutos. Pero el trabajo del Planificador no es fácil, para entenderlo debemos tener en cuenta dos factores:
El planificador trabaja para cualquier consulta. No es viable programar un planificador específico para nuestra aplicación, así que nos tenemos que conformar con el planificador de MySQL. Este está optimizado para “cualquier aplicación”. Y, aunque acumula los años de experiencia de los programadores de MySQL y utiliza estadísticas de ejecución para decidir cuál será el mejor plan, no siempre acertará.
En segundo lugar, el planificador no tiene tiempo de encontrar la solución óptima. Sería absurdo que utilizara tres segundos en planificar una consulta que, en el peor de los casos, sólo requerirá dos segundos para resolverse. El planificador debe encontrar el mejor plan posible, en el menor tiempo posible.
Por eso necesitamos conocer cómo trabaja, qué decisiones toma y, sobre todo, como influir en sus decisiones cuando nos convenga.
Centrándonos en lo importante, el planificador debe decidir dos aspectos principales en el plan de ejecución: qué índice se va a utilizar para resolver la consulta y en qué orden se realizarán los joins de las tablas.
Para elegir el índice que se utilizará en la consulta, el Planificador de MySQL busca los índices aplicables, consulta sus estadísticas y elige el índice que, en su opinión, implique consultar un menor número de registros.
Resulta evidente la importancia que adquieren las estadísticas de los índices que almacena MySQL.
Si no están actualizadas, el planificador puede elegir utilizar un índice que, según sus estadísticas, devolverá 10 resultados y encontrarse con que realmente devuelve 300.000.
Para evitar la degradación de rendimiento resulta vital analizar y optimizar las tablas periódicamente, sobre todo si el número de registros varía frecuentemente. Para ello debemos utilizar los comandos ANALYZE TABLE y OPTIMIZE TABLE. Esto hará que el Planificador tenga estadísticas actualizadas al elegir el índice.
También es necesario tener cuidado con los procedimientos almacenados. Existe la creencia de que los procedimientos almacenados son más rápidos porque su plan de ejecución ya está compilado... Pero probablemente este plan se compiló durante el desarrollo de la aplicación, con tablas pobladas con escasos datos de pruebas e incluso sin alguno de los índices que pudieron crearse posteriormente. Es decir, si no tenemos cuidado, los procedimientos almacenados se estarán ejecutando con planes anticuados. Y entonces pueden llegar a ser mucho más lentos que una consulta cuyo plan de ejecución se compile con información actualizada.
El otro punto crítico del Planificador es decidir el orden en que se harán los Joins.
Aquí influye algo más que la actualización de los índices. Si imaginamos una consulta con 7 tablas y un índice por tabla (algo no muy infrecuente), vemos que MySQL tiene que analizar más de 5.000 combinaciones posibles para el orden en el que efectuará los joins (exactamente 7! = 5040). De hecho, puede tardar varios segundos en encontrar un plan de ejecución para una consulta que se ejecutará en décimas de segundo.
En estas situaciones, lo mejor es utilizar STRAIGHT JOIN para indicarle a MySQL el orden en el que queremos que haga el Join de las tablas y ahorrándole así el trabajo.
Para conocer la forma en la que MySQL ejecutará una sentencia determinada tenemos la sentencia EXPLAIN que nos mostrará el plan de ejecución que MySQL ha
compilado para una consulta. EXPLAIN es extremadamente útil para conocer la configuración de índices en las tablas, los índices que podrían ser configurados para mejorar su rendimiento, el número de filas que se revisan, el tipo de query, etc.
Dependiendo de la complejidad de la consulta necesitaremos tiempo y paciencia para interpretar el plan de ejecución de MySQL y decidir si es el más adecuado. Mediante EXPLAIN podremos detectar planes de ejecución poco eficientes que hagan lentas nuestras consultas.
Para influir en el plan de ejecución tenemos varias acciones posibles:
Crear índices: La primera opción para mejorar el rendimiento de una consulta es la creación de índices. Siempre podemos evitar que MySQL tenga que escanear toda una tabla comparando el valor de una columna si definimos el índice adecuado sobre ella. Pero cuidado porque la creación de índices también tiene inconvenientes. Los índices penalizan las consultas de inserción y modificación. En muchas aplicaciones esto no será un problema, y será rentable crear índices que mejoren las consultas de SELECT a costa de ralentizar los INSERT y UPDATE. Pero en algunas aplicaciones con entradas masivas y simultáneas de datos, esto puede ser un problema.
Usar Correctamente los Índices: En ocasiones, puede que el índice adecuado ya exista, pero que MySQL decida no utilizarlo. Ya hemos dicho que el planificador no es perfecto, no tiene tiempo de serlo si quiere resolver la consulta en un tiempo prudente. Así que, en ocasiones, veremos que el plan de ejecución no utiliza el índice adecuado. Podemos proponer a MySQL una lista de índices a considerar, descartando otros, con el modificador USE INDEX. También podemos obligarle a utilizar un índice concreto con FORCE INDEX, e incluso podemos indicarle que ignore una lista de índices con IGNORE INDEX. Pero normalmente los problemas con los índices no son achacables al planificador: o bien no se han actualizado las estadísticas o bien no se utilizan correctamente los índices. Ya hemos insistido en la importancia de actualizar las estadísticas con ANALIZE TABLE y OPTIMIZE TABLE.
3.4
Ejecución
Durante la ejecución MySQL ejecuta el plan trazado, por lo que apenas tiene relevancia en el rendimiento de la consulta, salvo que la consulta esté devolviendo grandes conjuntos de resultados.
Al resolver una consulta, MySQL bloqueará la tabla contra escrituras para garantizar la integridad de los datos. Esto puede ser un problema si el resultado es grande y el cliente es lento en procesarlo (conexión lenta, máquina de pequeña capacidad...). En estos casos la tabla quedará bloqueada impidiendo el acceso de escritura a otros usuarios. Podemos solucionarlo indicando a MySQL que almacene el resultado en una tabla temporal utilizando SQL_BUFFER_RESULT y liberar así la tabla. Además, si ya sabemos que el resultado de una consulta va a ser grande, podemos
avisar al planificador con la opción SQL_BIG_RESULT. De esta forma, podrá tomar decisiones más agresivas y buscar un plan de ejecución mejor.
A modo de conclusión, si como vimos en el apartado anterior, el diseño del modelo de datos es crítico para el rendimiento futuro de nuestra aplicación, la optimización de consultas es la técnica que necesitamos dominar para optimizar el rendimiento actual.
Cuando el rendimiento de nuestra aplicación se degrada, y detectamos que se debe a la lentitud de algunas consultas, no será fácil optimizar el modelo de datos, pero sí podremos optimizar las consultas. Si la consulta está bien diseñada, las estadísticas están actualizadas y se utilizan los índices correctos; apenas habrá nada que hacer. Las mejoras serán de un 10-30%. Pero si alguna de estas cosas falla, podremos mejorar el rendimiento radicalmente. La diferencia entre una consulta que debe escanear 200.000 registros y luego ordenarlos frente a la misma consulta debidamente optimizada para evitar el escaneo y obtener directamente la ordenación del índice utilizado puede de ser de hasta tres órdenes de magnitud o incluso superior. Y eso, en una aplicación lenta, traza la diferencia entre la desesperación de los usuarios y su satisfacción.
Además de las opciones anteriores, existen diferentes herramientas de software cómo MySQL Query Analyzer o MySQLTUNER que monitorizan las consultas SQL del servidor y detectan el origen de los problemas. No obstante, con lo visto hasta ahora y unos conocimientos adecuados de administración de base de datos puede ser suficiente para solucionar cualquier problema que se presente.
4.
Mejorar la configuración del servidor MySQL
Son muchas las estrategias que podemos seguir para optimizar el rendimiento en el servidor.
La documentación oficial de MySQL recomienda algunas cómo la utilización de un SO Solaris o Linux con kernel mayor o igual al 2.4 para aprovechar al máximo las múltiples CPU del servidor o deshabilitar la partición de swap si se dispone de suficiente RAM.
También podemos mejorar la entrada/salida del disco utilizando un disco dedicado para almacenar las bases de datos de MySQL e incluso distribuir los datos en diferentes discos con el fin de mejorar las búsquedas.
Otra mejora para la entrada/salida es almacenar los logs en un disco diferente del que se utiliza para los datos.
Además, existen varias variables en MySQL que nos permiten optimizar su rendimiento:
table_open_cache: número máximo de tablas abiertas para todos los threads. Dependerá del valor dado a max_connections.
max_connections: define el número de conexiones a MySQL simultáneas. Por defecto 151 (150 más la consola local). Si se alcanza este límite aparecerá el error de "Unable to connect to database: Too many connections" y claramente será necesario aumentar éste valor.
wait_timeout: define el número de segundos de timeout para una conexión no interactiva. De esta forma, se evitará tener procesos en estado "sleep" en mysql que no se cierren y que por tanto pongan en peligro el valor "max_connections" tmp_table_size / max_heap_table_size: MySQL usará el menor valor de entre
"tmp_table_size" y "max_heap_table_size" para determinar el límite que puede ocupar una tabla temporal en memoria. Si una tabla temporal en memoria excede este límite, MySQL cogerá la tabla y la meterá en disco como una tabla MyISAM.
Otra posibilidad muy interesante de cara a mejorar el rendimiento de nuestro SGBD es la de montar un entorno en el que se tienen varios servidores, cada uno con una réplica de las bases de datos. De esta manera, el servidor con el rol de máster es el único que permite lecturas y escrituras, mientras que el resto de servidores, con el rol de slaves, únicamente permiten lecturas, y se encargan de actualizar sus datos con las modificaciones que reciben del master.
Está claro que este tipo de entornos mejora el rendimiento de cualquier aplicación, al repartir la carga de trabajo de la base de datos entre varios servidores. Además, se puede usar un balanceador de carga para los slaves, de manera que podamos incluir más slaves según lo necesitemos.
EJERCICIOS
1. Explica los factores que inciden en el rendimiento del servidor tras varios años de funcionamiento.
2. ¿Es capaz MySQL de gestionar grandes bases de datos con una alta concurrencia?
3. ¿Cuál es la herramienta más conveniente para monitorizar el sistema? 4. ¿Son convenientes las herramientas gráficas de monitorización?
5. ¿Cuáles son los 3 métodos que nos ayudan a mejorar el rendimiento del sistema? 6. ¿Es posible modificar el modelo de datos una vez puesto el sistema en
producción?
7. ¿Sobre qué dos aspectos podemos trabajar para optimizar el modelo de datos? 8. ¿En qué casos es conveniente utilizar el motor de datos MyISAM?
9. ¿En qué casos es conveniente utilizar el motor de datos InnoDB? 10. ¿En qué casos se utilizan otros motores de datos?
11. Hablando en términos de rendimiento ¿es un modelo de datos mejor cuándo está normalizado? Ilústralo con un ejemplo.
12. ¿Es mejor ordenar una tabla de cara a mejorar el rendimiento en una BD?
13. ¿Es mejor utilizar tipos de variables fijas o dinámicas de cara a mejorar el rendimiento de una BD? Explica por qué.
14. ¿Qué comando podemos utilizar para desfragmentar tablas?
15. ¿Es conveniente forzar a las columnas de una tabla a que no contengan valores NULL de cara a mejorar el rendimiento de la BD?
16. ¿En qué tipo de operaciones se va degradando poco a poco la aplicación?
17. ¿Cómo se empiezan a manifestar los fallos en el rendimiento de una BD? ¿Es repentino?
18. ¿Para qué utilizamos el comando SHOW PROCESSLIST?
19. ¿Podemos activar el Log General para detectar problemas de rendimiento en una BD?
20. ¿Cómo se activaría el Log General de errores?
21. ¿Podemos activar el Slow Query Log para analizar el rendimiento de la BD? ¿Cómo lo activaríamos?
22. Si una consulta está registrada una sola vez en el Slow Query Log ¿significa eso que es la responsable de la ralentización del sistema?
23. Indica resumidamente cómo es el proceso de consulta en MySQL 24. ¿Qué proceso conocemos con el nombre de “parseo”?
25. ¿Cómo procede MySQL al recibir una consulta que tiene en su caché?
26. ¿Cómo afectan las consultas de modificación de datos a la caché de MySQL? 27. Indica las variables que conozcas que modifiquen aspectos de la caché de
MySQL. Explica cada una de ellas.
28. ¿Son convenientes las consultas largas de cara a mejorar el rendimiento de la BD?
29. ¿Existe un planificador para cada aplicación?
30. ¿Tarda mucho tiempo el planificador en encontrar la solución más óptima? 31. ¿Sobre qué dos aspectos principales tiene que decidir el planificador? 32. ¿Son importantes las estadísticas de los índices que almacena MySQL?
33. ¿Para qué utilizamos los comandos ANALYZE TABLE y OPTIMIZE TABLE? 34. ¿Son más rápidos los procedimientos almacenados?
35. ¿Para qué utilizamos el comando EXPLAIN?
36. ¿De qué manera podemos influir en el plan de ejecución de una consulta?
37. ¿La fase de ejecución de una consulta tiene relevancia en el rendimiento de la BD? ¿En qué casos?
38. Nombra algunas herramientas de software que permiten optimizar las consultas en MysQL.
39. ¿Qué estrategias recomienda la documentación oficial de MySQL para mejorar el rendimiento del servidor?
40. ¿Cómo podemos mejorar la entrada/salida del disco en el servidor?
41. ¿Qué variables MySQL permiten mejorar el rendimiento del servidor? Explica cada una de ellas.
42. ¿Es conveniente montar un entorno con varios servidores de cara a mejorar el rendimiento de la BD? ¿Por qué? ¿Qué permitiría el servidor con rol de máster y los servidores con roles de slaves?
