Está en la página 1de 7

OPTIMIZACION DE CONSULTAS Y DCL

Presentado por: YEISON BARRIOS FUNIELES.

Introducción

Es bastante común que en nuestras aplicaciones haya alguna sección de informes, históricos, búsquedas generales… en la que se acaben consultando una gran cantidad de registros provenientes de varias tablas a la vez. Si estas tablas son grandes (varias centenas de miles de registros, o incluso millones), la optimización de las consultas pesadas supondrá la diferencia entre tener una aplicación fluida o tener una aplicación inmanejable.

Para los ejemplos de este tutorial hemos empleado una base de datos de testing. Se trata de una base de datos con unos 30 registros de empleados y alrededor de 100 registros de salarios. La estructura de las tablas es la siguiente:

con unos 30 registros de empleados y alrededor de 100 registros de salarios. La estructura de

Antes de empezar a cambiar nada, lo primero que recomendamos es ejecutar el comando EXPLAIN sobre esa consulta. De esta manera podemos saber qué pasos sigue el gestor de la base de datos para realizarla, y de qué manera accede a las tablas en cada uno de ellos. Con esto podremos identificar posibles cuellos de botella.

Del resultado de este comando, en lo que más nos vamos a fijar en este tutorial es:

El orden de tablas.

La columna Key: indica el índice que se está empleando para acceder a esa tabla concreta (si lo hubiera)

La columna type: indica el tipo de acceso a la tabla. Los posibles valores, de mejor a peor, son:

datos consulta las

las

filas:

es

el

orden en que

la base

de

systemdatos consulta las las filas: es el orden en que la base de const eq_ref ref

constconsulta las las filas: es el orden en que la base de system eq_ref ref fulltext

eq_reflas las filas: es el orden en que la base de system const ref fulltext ref_or_null

las filas: es el orden en que la base de system const eq_ref ref fulltext ref_or_null

las filas: es el orden en que la base de system const eq_ref ref fulltext ref_or_null

las filas: es el orden en que la base de system const eq_ref ref fulltext ref_or_null

ref

fulltext

ref_or_null

index_mergeque la base de system const eq_ref ref fulltext ref_or_null unique_subquery index_subquery range index ALL Si

unique_subqueryde system const eq_ref ref fulltext ref_or_null index_merge index_subquery range index ALL Si algún acceso de

index_subqueryeq_ref ref fulltext ref_or_null index_merge unique_subquery range index ALL Si algún acceso de la consulta es

ref_or_null index_merge unique_subquery index_subquery range index ALL Si algún acceso de la consulta es del tipo

ref_or_null index_merge unique_subquery index_subquery range index ALL Si algún acceso de la consulta es del tipo

ref_or_null index_merge unique_subquery index_subquery range index ALL Si algún acceso de la consulta es del tipo

range

index

ALL

Si algún acceso de la consulta es del tipo index o ALL, deberíamos revisar esa parte de la consulta, a menos que queramos expresamente listar o calcular todos los registros de la tabla.

OPTIMIZACIONES

GROUP / ORDER BYOPTIMIZACIONES Por simplicidad vamos a referirnos a la cláusula GROUP BY , pero teniendo en cuenta

Por simplicidad vamos a referirnos a la cláusula GROUP BY, pero teniendo en cuenta que todo se aplica también aORDER BY.

Esta cláusula puede suponer un verdadero cuello de botella cuando el número de registros a agrupar es muy elevado (independientemente de que se use la cláusula LIMIT, pues esta se aplica después del GROUP BY).

Hay que procurar que todas las columnas presentes en el GROUP BY formen parte del mismo índice de la tabla que se está consultando, en el mismo orden que en la consulta. Si la consulta es muy importante en nuestra aplicación, podemos valorar la posibilidad de definir un índice para optimizarla. Elegiríamos primero la columna/s filtrada en el WHERE, y después aquellas presentes en el GROUP BY.

INNER JOIN con GROUP / ORDERel WHERE , y después aquellas presentes en el GROUP BY . Este es un caso

Este es un caso digno de mención. En una consulta con varios INNER JOIN es el optimizador quien decide el orden de consulta de las tablas, dependiendo de las restricciones y el uso de los índices. Esta decisión suele ser acertada, con una excepción: puede no ser el orden óptimo para efectuar el GROUP BY (o el ORDER BY).

En este caso necesitamos colocar primero la tabla sobre la que se está haciendo el GROUP BY y forzar al optimizador a que lea primero esa tabla. De esta manera, el GROUP BY se realizará de una sola pasada, debido a que los resultados ya estarán ordenados con respecto al índice. Esto lo conseguimos con STRAIGHT_JOIN, que no es más que un INNER JOIN con la particularidad de que fuerza la lectura de la tabla de la izquierda antes que la de la derecha.

Con los LEFT JOIN no ocurre este problema, pues en este caso la tabla de la izquierda SIEMPRE se leerá antes que su tabla dependiente.

Hablemos un poco sobre los Procedimientos de Almacenado PA.

Pues bien, lo primero que explicaré será el comando DROP PROCEDURE IF EXISTS, este comando sirve para eliminar el PA si previamente existe (NOTA: este debe ser agregado antes del DELIMETER), esto es útil por ejemplo cuando estamos modificando nuestro PA y necesitamos estar actualizandolo constantemente, la sintaxis sería así:

DROP PROCEDURE IF EXISTS myProcedure;

Bien, una vez visto eso, el siguiente comando que veremos será el DELIMETER, se refiere a escribir un delimitador para nuestras consultas SQL, este delimitador se debe específicar cuando vamos a tener varias consultas dentro de nuestro PA para decirle a MySQL que todo lo que este dentro de ese delimitador formará parte de ese PA, tu puedes elegir cualquier delimitador, pero entre los más comunes están:

DELIMETER //

O bien:

DELIMETER $$ $$

Después de escribir nuestro delimitador, vamos a crear nuestro PA con el comando CREATE PROCEDURE, cuya sintaxis debe ser así:

CREATE PROCEDURE myProcedure({[PARAMS]}) BEGIN

END

Sin duda muchos verán que esto es similar a cuando programabas en Pascal o un lenguaje prehístorico dónde tenías que específicar los bloques de INICIO y FIN, y los parámetros aquí son opcionales.

Parámetros

Cuando creamos un nuevo PA los parámetros son opcionales y sin duda estos son de gran ayuda cuando necesitamos pasar algunos valores, la forma de específicar estos parámetros es la siguiente:

CREATE PROCEDURE myProcedure( IN _language VARCHAR(2), IN _page INT, IN _max INT) BEGIN

END

Cuando son muchos parámetros una buena técnica de separación y para poder ordenar y ver mejor los parámetros es dar un enter a cada uno y separarlos por comas (,). La sintaxis para estos parámetros es simplemente escribir el comando IN seguido del nombre del parámetro (recomiendo poner guiones bajos al principio de cada parámetro, leer la explicación en el siguiente párrafo) y después específicar su tipo (INT, VARCHAR, TINYINT, etc.). Por ultimo

Para mandar a llamar los PA simplemente se utiliza el comando CALL en nuestra query.

CALL myProcedure(1, 2, 'Valor string', 3);

DCL (Data Control Language) Lenguaje de Control de Datos

En inglés DATA CONTROL LANGUAGE, es el lenguaje de control de datos, que incluye una serie de comandos que permiten al administrador controlar el acceso a los datos contenidos en la base de datos

Es la parte menos conocida de Sql, siendo la finalidad controlar el acceso a datos denegando y otorgando privilegios sobre los objetos existentes.

COMMIT: Guarda los trabajos realizados en las transacciones ROLLBACK: Restaura la base de datos al estado original desde el comando COMMIT pasado en las transacciones SAVEPOINT: establecer un punto en que es posible un ROLLBACK. SAVE TRANSACTION: Establece un punto de almacenamiento dentro de una transacción

un punto de almacenamiento dentro de una transacción COMANDO BACKUP El backup es una palabra inglesa

COMANDO BACKUP

El backup es una palabra inglesa que en ámbito de la tecnología y de la información, es una copia de seguridad o el proceso de copia de seguridad. Backup se refiere a la copia y archivo de datos de la computadora de modo que se puede utilizar para restaurar la información original después de una eventual pérdida de datos. La forma verbal es hacer copias de seguridad en dos palabras, mientras que el nombre es copia de seguridad.

Los respaldos tiene dos propósitos diferentes, el primer propósito es la recuperación de datos después de su pérdida ya sea por la eliminación o corrupción de datos, la pérdida de datos puede ser una experiencia común de los usuarios de computadoras. Una encuesta de 2008 encontró que el 66 % de los encuestados había perdido los archivos en su ordenador doméstico.

El segundo propósito de las copias de seguridad es la recuperación de los datos de una época anterior, de acuerdo con una política de retención de datos definidos por el usuario, que por lo general es configurado en una aplicación de copia de seguridad de cómo se requieren largos copias de los datos, aunque las copias de seguridad representan popularmente una forma simple de recuperación de desastres y deben formar parte de un plan de recuperación de desastres por sí mismos.

Una de las razones de esto es que no todos los sistemas de copia de seguridad o aplicaciones de copia de seguridad son capaces de reconstruir un sistema informático u otras configuraciones complejas, como un clúster de ordenadores, que son servidores de directorio activo o un servidor de base de datos, mediante la restauración de sólo los datos de una copia de seguridad.

restauración de sólo los datos de una copia de seguridad. REVOKE Quita un permiso concedido o

REVOKE Quita un permiso concedido o denegado previamente.

Sin taxis

Simplified syntax for REVOKE REVOKE [ GRANT OPTION FOR ]

{

 

[ ALL [ PRIVILEGES ] ]

|

permission [ ( column [ ,

n

]

)

]

[

,

n

]

}

[

ON [ class :: ] securable ]

{ TO | FROM } principal [ ,

n ]

[ CASCADE] [ AS principal ]