Guía para La Optimización de Consultas

UNIVERSIDAD AUTONOMA GABRIEL RENE
MORENO
FACULTAD DE CIENCIAS EXACTAS Y
TECNOLOGIA
Carrera de Ingeniería Informática
Proyecto de Grado
“Guía para la Optimización de Consultas
en una Base de Datos Relacional Utilizando
SQL”
Proyecto de Grado para optar al Título de:
Licenciatura en Ingeniería Informática
Elaborado por: Ubaldo Pérez

Ferreira
Santa Cruz de la Sierra – Bolivia

Temario
• Parte I. Perfil del Proyecto.

– Antecedentes.
– Justificación.
– Objetivos.
• Parte II: Fundamentos Teóricos.
– Modelo de Datos Relacional.
– Lenguajes Relacionales.
– Sistemas de Gestión de Base de Datos Relacionales.
– Conceptos del Procesamiento de Consultas.
– El Optimizador de Consultas.
• Parte III: Propuesta y Aplicación de la Guía para la Optimización de
Consultas.
– Descripción de la Guía Propuesta
• Consideraciones Previa para el Uso de la Guía.
• Paso 1. Generar y analizar el Plan de Ejecución.
• Paso 2. Reescribir la consulta SQL.
• Paso 3. Crear y Gestionar Indices.
• Paso 4. Ajuste al Esquema de la Base de Datos.
– Aplicación de la Guía Propuesta
• Consideraciones Previa para el Uso de la Guía.
• Ejemplo 1.
• Ejemplo 2.
• Ejemplo 3.
• Conclusiones y Recomendaciones.
Parte I - Perfil del Proyecto
Antecedentes En las Aplicación Productiva, existe la posibilidad de encontrar

Justificación algunas Consultas SQL, que al momento de ejecutarse, generen
Objetivos problemas en el SBD, tales como:
-Elevada carga del CPU

-Bloquean procesos de trabajo durante largo tiempo.
-Leen muchos bloques de datos a la memoria intermedia
(Paginamiento)
-Los discos están fuertemente cargados.
Y por supuesto estos problemas son la causa de:

Malestar entre los usuarios y/o clientes.
Mala imagen corporativa, etc.
Las Consultas SQL que generan este tipo de problema, se las

denomina “COSTOSAS” o “INEFICIENTES”.
Antecedentes ¿Que hacer cuando se presenta una

Justificación Consulta SQL costosa?
Objetivos
¿Por donde empezar?, si no se

cuenta con pasos bien
definidos, resolver el problema
de una Consulta SQL costosa,
puede tomar horas de trabajo.
Es así, que se propone una

Guía para resolver el
problema de las Consultas
SQL costosas.
Antecedentes
Justificacion
Objetivo principal.
Objetivos • Diseñar una Guía para la Optimización de
Consultas en una Base de Datos Relacional
utilizando SQL .
Objetivos Específicos.
– Describir las Fases del Proceso de Optimización de
Consultas.
– Detallar los componentes y funcionamiento de un
Optimizador de Consultas.
– Exponer el contenido de un Plan de Ejecución.
– Detallar las reglas para evitar formular Consultas SQL
costosas.
– Detallar las reglas para Crear y Gestionar índices.
– Explicar el contenido de las Estadísticas del Catalogo
de Base de Datos.
Parte II - Fundamentos Teóricos
Modelo El Modelo de Datos Relacional (MDR) fue propuesto por Edgar

Relacional
Lenguajes
Frank, Codd en 1970.
Relacional
Sistema de
Base de Datos Este Modelo, se fundamenta en la TEORIA MATEMATICA DE
El Proceso de CONJUNTOS, de ahí, su potencial.
Optimización
de Consultas
Los conjuntos en el MDR son denominados Dominios (D).
El Optimizador
de Consultas
Un Dominio es un conjunto de valores escalares del mimo tipo.
La única herramienta de Estructura de Datos usada por este

Modelo es una Relación (R).
04/26/10 07:13 PM
Modelo
Relacional
Lenguajes Una Relación R , es representada como una Tabla.
Relacional
Sistema de Grado (n) Atributo, papel que desempeña D en R.
Base de Datos
Cardinalidad (m).
El Proceso de
Optimización A1 …
ESQUEMAAn
de Consultas
El Optimizador … IA
de Consultas
N C Tupla, conjunto de valores t1…tm,
V1 … TA Vn
NS
I… ti=(v1,…,vn) / v1 ∈ A1 ∧… ∧vn ∈ An
Restricciones de Integridad sobre las Relaciones.

Una Llave Primaria (PK), es un atributo o un conjunto de
atributos, que sirven para identificar una fila una relación. No se
permiten valores NULOS en PK.
Una Llave Foranea (PF), es uno o mas atributos comunes entre
dos Relaciones.
04/26/10 07:13 PM
Modelo El Algebra Relacional: Es un lenguaje PROCEDIMENTAL, y consiste

Relacional
en un conjunto de operaciones de alto nivel que operan sobre
Lenguajes
Relacional Relaciones
Sistema de
Base de Datos Operaciones Básicas
El Proceso de
Optimización Selección (σ )
de Consultas Operaciones Unarias
El Optimizador
de Consultas
Proyección (Π )
Producto Cartesiano (Χ )
Unión (∪) Operaciones Binarias
Diferencia (-)
Operaciones adicionales
Intersección (∩) Estas operaciones pueden
ser expresadas sobre la
Reunión con predicado(|X|p)
base de las primeras cinco
Reunión natural (|X|)
División (÷ )
Modelo
Relacional
Lenguajes
Expresión Algebraica. Las operaciones del Algebra Relacional,
Relacional son formuladas dentro de una Expresión Algebraica; las mismas que
Sistema de
Base de Datos
especifican la manera en que los datos deben ser recuperados de las
El Proceso de Relaciones.
Optimización
de Consultas
El Optimizador
de Consultas
A B C
aaa 111 234 Π A,B,X (σ X=“aa” (R1XR2)) A B X
aaa 111aa
R1bbb 222 213
ccc 123 234 Aplicando la bbb 222aa

Expresión Algebraica
ccc 123aa
X Y
El resultado de una Expresión
R2aa uu Algebraica es uma nueva Relación
bb ss
Modelo
Relacional
Árbol Algebraico. Las Expresiones Algebraicas, pueden ser
Lenguajes
Relacional representada en su totalidad en un Árbol Algebraico.
Sistema de
Base de Datos
El Proceso de
Π A,B,X (σ X=“aa” (R1XR2))
Optimización
Π A,B,X
de Consultas
El Optimizador
3ro. Proyectar A,B,X
de Consultas
σ X=“aa” 2do. Seleccionar las tuplas con X=“aa”
Lectura de abajo
hacia arriba X 1ro. Producto Cartesiano
R1 R2
Herramienta Básica utilizada por los SGBD.
Modelo
Relacional Lenguaje SQL (Structure Query Languaje). Implementado
Lenguajes
Relacional
en la mayoría de los SGBD, es un lenguaje NO
Sistema de PROCEDIMENTAL, al igual que el Algebra Relacional opera sobre
Base de Datos
Relaciones
El Proceso de
Optimización La mayoría de las operaciones del Algebra relacional pueden ser
de Consultas
El Optimizador
formuladas en el SQL.
de Consultas
La Estructura Básica de una expresión en SQL esta compuesta de
tres cláusulas:
SELECT A1, A2,...,An // Que atributos
FROM r1, r2,...,rm // De que relaciones
WHERE P // Que tuplas
[GROUP BY A1, A2,...,An] // Agrupador

[HAVING PG] // Predicado para el grupo
Modelo
Relacional Sistema de Gestión de Bases de Datos (SGBD). Es el
Lenguajes
Relacional conjunto de Programas que permiten: Definir y
Sistema de
Base de Datos
Manipular la información que contienen las Bases de
El Proceso de
Optimización
Datos, entre otras tareas que realiza como ser:
de Consultas Autorizaciones, Seguridad, Recuperación
El Optimizador
de Consultas
Modelo
Programa de
Relacional Aplicación
Compilador
Lenguajes
LMD
Relacional Consulta de Usaurio Esquema de
Sistema de BD
Base de Datos Procesador
Lenguaje SQL de Compilador
El Proceso de
Optimización Consultas LDD
de Consultas
El Optimizador
de Consultas Tabla de
Autorizacion Gestor Diccionario
De de Datos
Control de Base de Datos
Acceso
Adm. de Accesos
Concurrente Gestor
de
Archivos
Datos + Index
Modelo
Relacional El Proceso de Optimización de Consultas
Lenguajes
Relacional
Consulta Traductor
Sistema de Árbol
Base de Datos SQL (Parser) Relacional
El Proceso de
Optimización Reglas de Transformación de Expresiones
de Consultas
El Optimizador Estadísticas de las Relaciones. Diccionario
de Consultas
Medidas de Costos. de Datos
Ordenes Join. Optimizador

Selección del Plan Optimo de Consulta
Datos + Index
Resultado de la Motor de Plan de

Consulta Ejecucion Ejecución
Parte III – Propuesta y Aplicación de la Guía
Consideracion
es Previa
Consideraciones para el uso de Guía.
Descripción de
los Pasos de
La Guía debe ser vista como una herramienta mas en el proceso de
Guía Optimización de Consultas.
Aplicación de
la Guía
Propuesta La Guía es una herramienta de propósito general, en algunos casos
puede ser muy compleja o muy simple.
No esta orientada a un SGBD en particular

La Guía puede ser utilizada este o no poblada la Base de Datos.
La guía esta orientado a cierto de tipo de usuarios como ser:

Administradores de Base de Datos, Diseñadores de Base de
Datos y Programadores de Aplicaciones.
La guía esta fundamentada en la “Optimización de Rendimientos de
Sistemas” propuesta por SAP.
Paso 1 Estadísticas Obsoletas?
Generar el Plan de Ejecución
Consideracion Análisis del Plan de Ejecución
es Previa
Descripción de NO ¿Reescribir la
SI
los Pasos de Consulta?
Guía Paso 2 Orientar al uso de INDICES
Aplicación de Reescribir la Consulta Existentes?
la Guía
Propuesta Paso 1
NO ¿Ajustar y/o SI
Crear
Índices?
Paso 3
Crear INDICES?
Crear y Gestionar Índices
Ajustar los Existentes
Paso 1
NO ¿Ajustar el SI
Esquema de
BD Desnormalizar
Paso 4
Ajustar el Esquema de la BD Adicionar Atributos Derivados
Paso 1 Contin
ua
Entre otros, el Plan de Ejecución muestra el orden lógico en la cual se
Parte
acceden a las tablas y el método III – Propuesta
de acceso y Aplicación
que utiliza para leer cada tabla . de la Guía
Consideracion Paso 1. Generar el Plan de Ejecución

es Previa
Descripción de
los Pasos de
Verificar que las Estadísticas de las Tablas no sean Obsoletas.
Guía Actualizar las Estadísticas puede llevar horas de trabajo.
Paso 1.
Paso 2. Los SGBD proporcionan una herramienta llamada SHOWPLAN,
Paso 3. que muestra al usuario un detalle del Plan de Ejecución:
Paso 4.
Aplicación de
la Guía
¿Cual es el tiempo de ejecución de la consulta (ms, seg, min)?
Propuesta
¿Cuántas tuplas se estima recuperar?
¿Cuál es el costo de la consulta (interno SGBD)?
¿Se consideró los INDICES EXISTENTE en cada tabla o se está
realizando un FULL TABLE SCAN?
¿Se utilizan tablas temporales para procesar la consulta ?
¿Cuales son los órdenes de JOIN que utiliza el optimizador para
resolver la consulta ?
Consideracion
es Previa
Descripción de
Full Table Scan Vs. Index Scan
los Pasos de
Guía
Acceso Full Table Scan Acceso Index Scan
Paso 1.
200.00 1.20
Paso 2. 180.00
160.00 1.00
Paso 3. 140.00
Tiempo (min)
120.00 0.80
Tiempo (min)
Paso 4. 100.00
0.60
80.00
Aplicación de 60.00 0.40
la Guía 40.00
20.00 0.20
Propuesta 0.00
0.00
0
00
00
00
0
0
00
0
00
00
00
00
n1
00
00
00
00
00
00
00
n5
00
00
00
00
00
00
00
00
00
00
n1
00
00
n5
00
00
00
n5
n1
n2
n5
00
00
n5
n1
n2
n1
n2
n5
n1
n2
Cantidad de Tuplas Cantidad de Tuplas
Full Table Scan Index Scan
Si existe un acceso FULL TABLE SCAN,

en una consulta, esta tiene la probabilidad
de ser costosa a mayor cantidad de datos.
Consideracion Planes de Ejecución para diferentes SGBD.

es Previa
SELECT *
Descripción de
los Pasos de
FROM Customer WHERE customer_num = 101
Guía Motor de Base de Plan de Ejecución Análisis del Plan de Ejecución
Paso 1. Datos
Paso 2.
INFORMIX 1. SELECT statement La línea dos indica que INFORMIX accede
Paso 3. mediante un índice. La línea tres indica
2. INDEX PATH que el índice utilizado en idx_customer, la
Paso 4. 3. INDEX KEY: idx_customer línea cuatro indica que se utilizó el campo
Aplicación de 4. LOWER INDEX FILTER: customer_num como filtro
la Guía ( customer_num=101)
Propuesta
ORACLE 1. SELECT statement La línea dos indica que se especifica que
el acceso es vía índice y además
2. TABLE ACCES BY INDEX ROWID utilizando el filtro customer_num=101, la
customer_num=101 línea tres indica que el índice utilizado es
3. INDEX UNIQUE SCAN idx_customer el idx_customer.
SQL SERVER 1. SELECT statement La línea dos se indica que se utiliza el

índice idx_customer, la línea tres indica
2. CLUSTER INDEX SEEK (idx_customer) que la busque utilizo el filtro
3. SEEK:( customer_num=@101 customer_num=@101.
DB/2 1. SELECT statement La línea dos indica que se utilizo el filtro

customer_num=101, la línea tres indica
2. FETCH customer_num=101 que el índice esta ordenado, y en la línea
3. SORT cuatro se índica que se utiliza el índice
4. IXSCAN INDEX idx_customer idx_customer.
Volver
Consideracion Paso 2. Reescribir la Consulta.

es Previa
Descripción de
El SQL permite escribir una consulta de diferentes maneras, sin
los Pasos de
Guía
embargo, esto implica una estrategia de acceso diferente.
SELECT DISTINCT fname SELECT DISTINCT fname SELECT DISTINCT fname
Paso 1.
FROM customer FROM customer FROM customer
Paso 2.
WHERE customer_num IN WHERE customer_num = ANY WHERE EXISTS
Paso 3. (SELECT customer_num ( SELECT customer_num ( SELECT ∗ FROM ORDERS
Paso 4. FROM orders FROM orders WHERE customer.customer_num =
orders.customer_num
Aplicación de WHERE order_date = “20/01/1989”) WHERE order_date = “20/01/1989”)
la Guía AND order_date = “20/01/1989”)
Propuesta
SELECT DISTINCT fname SELECT DISTINCT fname SELECT DISTINCT fname
FROM customer, orders FROM customer FROM customer
WHERE customer.customer_num = WHERE (SELECT COUNT(∗) FROM orders WHERE “20/01/1989” IN
orders.customer_num
WHERE customer.customer_num = (SELECT order_date
AND order_date = “20/01/1989” orders.customer_num
FROM orders
AND order_date = “20/01/1989”)>0
WHERE customer.customer_num =
orders.customer_nu ).
SELECT DISTINCT fname SELECT fname

FROM customer FROM customer, orders
WHERE “20/01/1989” = ANY WHERE order_date=“20/01/1989”
(SELECT order_date AND P.customer_num = S.customer_num
FROM orders GROUP BY fname
WHERE customer.customer_num =
orders.customer_num)
Consideracion Reglas para evitar escribir Consultas SQL costosas.

es Previa
Descripción de R1. Transferir Pequeña Cantidad de Datos.
los Pasos de
Guía
R2. Usar los Campos Indexados en la Cláusula WHERE
Paso 1.
Paso 2. campo indexado = expresión
Paso 3. R3. Si existen Índices Compuestos, Utilice los Primeros Campos.
Paso 4.
Aplicación de
Si se tiene un índice compuesto con los campos A, B y C
la Guía
Propuesta
WHERE A=1 WHERE B=10
WHERE A>=12 AND A<=15 WHERE C=212
WHERE A=1 AND B<5 WHERE B>=12 AND C=15
Usa el índice No usa el índice
R4. Evitar el Uso de la Cláusula NOT IN
R5. Evitar Expresiones Regulares Difíciles en la Cláusula WHERE.
WHERE fname LIKE “*sen*”
WHERE total_price - 10 = 200 * (13/100) = 36
Consideracion Reglas para evitar escribir Consultas SQL costosas.

es Previa
Descripción de R6. Evitar no Iniciar una Serie de Substring
los Pasos de
Guía WHERE fname[4,2]=“SC”
Paso 1.
Paso 2. R7. Evitar Joins de Cadenas Largas
Paso 3.
WHERE TABLA1.nombre=TABLA2.nombre
Paso 4.
Aplicación de R8. Evitar Subconsulta Correlativas.
la Guía
Propuesta SELECT item FROM A
WHERE item IN (SELECT item FROM B WHERE B.num=50).
R9. Uso de la Cláusula UNION para Eliminar el Full Table Scan.

R10. Aplicar Criterios Sobre uno de los Lados del Join.
R11. Evitar el Uso de Funciones en la Cláusula WHERE.
SELECT * FROM customer
WHERE UPERCASE(fname)=”MARIO CLAROS”
Volver
R12. Usar Tablas Temporales para Agilizar la Consulta.
Consideracion Paso 3. Crear y Gestionar Índices.

es Previa
Descripción de
los Pasos de Los INDICES se utilizan para agilizar las búsquedas de información.
Guía
Paso 1.
Paso 2. Índices Primario, son creados sobre los
Paso 3. campos llaves primaria.
Paso 4. Tipos de Indices. Índices Secundarios, son creados sobre
Aplicación de
la Guía los campos llaves foráneas, o sobre
Propuesta
atributos con alta selectividad.
Mediante el uso de índices se evita el FULL TABLE SCAN.
¿Si los índices proporcionan celeridad, por qué no indexar todas las
columnas?.
Actualizar, borrar e insertar datos sobre una columna indexada
consume más tiempo.
Si hay muchos índices, existe la probabilidad de que el Optimizador
seleccione índice incorrecto.
Los índices en una tabla como regla de oro no mas de 5.
Consideracion Reglas para crear índices.

es Previa
Descripción de
los Pasos de
Guía R1. Campos Indexados en Criterios de Consultas. Los campos
Paso 1. definidos como PK ya están indexados, pero se deben investigar aquellos
Paso 2. campos que se incluyen en muchas consultas
Paso 3.
R2. Joins con Campos Indexados. Si existe un JOIN entre dos o mas tablas,
Paso 4.
los campos comunes obligatoriamente deben ser creados como índices.
Aplicación de
la Guía
Propuesta R3. Usar Índices de Múltiples Campos Cuando sea Necesario.
usar índices sobre campos sustitutos, en lugar de tener índices con campos
compuesto.
R4. Evitar Valores Nulos en un Índices. Si un atributo es definido como

índice, evite los valores NULL.
R5. Atributos en la cláusula ORDER BY. Si existen atributos que

aparecen frecuentemente en la cláusula ORDER BY, deben creados como indices
compuestos.
Consideracion Reglas para crear índices.

es Previa
Descripción de
los Pasos de
R6. Usar Índices Selectivos. Se deben indexar aquellos campos con alta
Guía SELECTIVIDAD.
Paso 1.
La selectividad de un atributo es:
Paso 2.
Paso 3. número de valores distintos/número de tuplas de la tabla.
Paso 4.
1000 registros, y una columna indexada de la tabla tiene 950 valores
Aplicación de
la Guía
diferentes, la selectividad del índice es 0.95 (950/1000).
Propuesta
La mejor selectividad es 1 (llaves primarias)
R7. Índices Compuestos Vs. Varios Índices con una Sola
Columna. Cuando se va a crear un índice compuesto, debe valorarse si la
selectividad de ese índice va a ser considerablemente mayor con varias columnas
que con una.
Volver
Consideracion Paso 4. Ajustar el Esquema de la Base de Datos.

es Previa
Descripción de
los Pasos de
Al realizar el diseño lógico se recomienda llegar, al menos, hasta la
Guía 3FN, para obtener un esquema con una estructura consistente y sin
Paso 1.
redundancias.
Paso 2.
Paso 3. Pero, a menudo, sucede que las BD Normalizadas no proporcionan
Paso 4. la máxima eficiencia a las Consultas SQL. Por lo tanto, hay que
Aplicación de
la Guía
volver atrás y desnormalizar, sacrificando los beneficios de la
Propuesta normalización para mejorar las Consultas.
Sin embargo hay que tener en cuenta los siguientes factores:
• La desnormalización hace que la implementación sea más compleja.
• La desnormalización hace que se sacrifique la flexibilidad.
• La desnormalización puede hacer que los accesos a datos sean más
rápidos, pero hace que las actualizaciones sean lentas.
Consideracion
es Previa
Reglas para la Desnormalización de Relaciones.
Descripción de
los Pasos de
Guía
• R1. Introducir atributos Derivados.
Paso 1.
• R2. Combinar Relaciones de 1:1
Paso 2.
Paso 3. • R3. Duplicar Atributos no Clave en Relaciones de 1:N para
Paso 4.
Reducir los Joins.
Aplicación de
la Guía
Propuesta • R4. Tablas de Referencias.
• R5. Duplicar Llaves Foráneas en Relaciones de 1:N para
Reducir los Joins.
• R6. Duplicar Atributos en Relaciones de N:M para Reducir los
Joins.
• R7. Introducir Grupos Repetitivos.
Volver
Consideracion
es Previa
Introducir atributos Derivados.
Descripción de
los Pasos de
Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de
la Guía
Propuesta
Volver
Consideracion
es Previa Duplicar Atributos no Clave en Relaciones de 1:N para Reducir
Descripción de
los Pasos de
los Joins.
Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de
la Guía
Propuesta
Volver
Consideracion
es Previa Tabla de Referencia.
Descripción de
los Pasos de
Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de
la Guía
Propuesta
Volver
Consideracion
es Previa Duplicar Llaves Foráneas en Relaciones de 1:N para Reducir los
Descripción de
los Pasos de
Joins.
Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de
la Guía
Propuesta
Volver
Consideracion
es Previa Duplicar Atributos en Relaciones de N:M para Reducir los Joins.
Descripción de
los Pasos de
Guía
Paso 1.
Paso 2.
Paso 3.
Paso 4.
Aplicación de
la Guía
Propuesta
Volver
Consideracion Esquema de la BD Valores.

es Previa
create table inv_header
Descripción de
los Pasos de ( nro_tran serial not null primary key,
Guía
nro_doc integer not null ,
Aplicación de
inv_header create table inv_detalle
la Guía fecha date not null , …
Propuesta ( nro_tran integer not null ,
1
ing_egr char(1) not null ,
tien orden integer not null ,
e cod_tv smallint not null ,
N nro_valor integer …
inv_detalle foreign key (nro_tran) references inv_header,

primary key (nro_tran,ing_egr,orden,cod_tv,nro_valor),
Nombre Tamaño de la tabla Numero de Filas Tamaño de la Tabla

Tabla (Bytes) (Mbyte)
inv_header 64 36,162 2.20

inv_detalle 26 3,840,140 95.21
Consideracion Optimización Consulta Nro. 1.

es Previa
Descripción de
los Pasos de select * from inv_header Listar el detalle de valores de las
Guía where nro_tran=100 or nro_tran=300 transacciones numero 100 y 300.
Aplicación de
la Guía
Propuesta
PASO 1.
Ejemplo 1.
QUERY:
Ejemplo 2. Resultado
Ejemplo 3. ------
select * from inv_header Tiempo: 4.1 min.
where nro_tran=100 or nro_tran=300 Método de Acceso: FULL TABLE SCAN
Estimated Cost: 2
Estimated # of Rows Returned: 2
1) inv_header: SEQUENTIAL SCAN Análisis
Filters: (inv_header.nro_tran = 100 OR
Existe un índice sobre el campo nro_tran, sin
inv_header.nro_tran = 300 ) embargo no fue utilizado, esto debido a que
la cláusula WHERE no es SARGABLE.

es Previa PASO 1.
Descripción de PASO 2. QUERY:
los Pasos de Solución. ------
Guía
Aplicación de Reescribir la consulta, para que la select * from inv_header where nro_tran=1
la Guía cláusula WHERE sea SARGABLE, se union
Propuesta utilizo la Regla 9 del paso 2.
select * from inv_header where nro_tran=300
Ejemplo 1.
Ejemplo 2.
Estimated Cost: 2
select * from inv_header where nro_tran=100 Estimated # of Rows Returned: 2
Ejemplo 3.
union 1) inv_header: INDEX PATH
select * from inv_header where nro_tran=300 (1) Index Keys: nro_tran
Lower Index Filter: inv_header.nro_tran = 100
Union Query:
------------
1) inv_header: INDEX PATH
(1) Index Keys: nro_tran
Lower Index Filter: inv_header.nro_tran = 300
Resultado.
Tiempo: 0.01 min.
Método de Acceso: INDEX PATH

es Previa
Descripción de
los Pasos de select * from inv_detalle Listar el detalle de movimiento de la factura
Guía where cod_tv=2 and nro_valor=700021 numero 700021.
Aplicación de
la Guía PASO 1. Resultado.
Propuesta
Ejemplo 1. QUERY:
Tiempo: 8.3 min.
Ejemplo 2. ------
Ejemplo 3. select * Método de Acceso: FULL TABLE SCAN
from inv_detalle
Análisis
where cod_tv=2 and nro_valor=700021
Estimated Cost: 2 No existe un índice sobre los campos cod_tv
y nro_valor, esta situación hace que el
SGBD se decida por un acceso FULL
1) inv_detalle: SEQUENTIAL SCAN
TABLE SCAN.
Filters: (inv_detalle.cod_tv = 2 AND
inv_detalle.nro_valor = 700021 )

es Previa
Descripción de
Análisis. QUERY: PASO 1.
los Pasos de
Guía Se observa que la cláusula WHERE es ------
Aplicación de de tipo SARGABLE, sin embargo la select *
la Guía tabla inv_detalle no cuenta con los
Propuesta from inv_detalle
índices adecuado.
Ejemplo 1. where cod_tv=2 and nro_valor=700021
Ejemplo 2. PASO 3.
Solución. Estimated Cost: 2
Ejemplo 3.
Se procedió a crear un índice: Estimated # of Rows Returned: 1
1) informix.inv_detalle: INDEX PATH
CREATE INDEX idx_inv_detalle1
ON inv_detalle(cod_tv, nro_valor). (1) Index Keys: cod_tv nro_valor
Lower Index Filter: (informix.inv_detalle.cod_tv = 2 AND
informix.inv_detalle.nro_valor = 700021 )
Resultado.
Tiempo: 0.01 min.
Método de Acceso: INDEX PATH

es Previa
Descripción de select inv_detalle.* from inv_header,inv_detalle
los Pasos de Listar el detalle de movimiento de valores
Guía where inv_header.nro_tran=inv_detalle.nro_tran correspondiente al mes de enero del 2004.
Aplicación de and year(fecha)="2004" and month(fecha)="01"
la Guía
Propuesta
QUERY: PASO 1.
Ejemplo 1. Resultado
------
Ejemplo 2. Tiempo: 10.4 min.
select inv_detalle.* from inv_header,inv_detalle
Ejemplo 3.
where inv_header.nro_tran=inv_detalle.nro_tran Método de Acceso: FULL TABLE SCAN
and year(fecha)="2004" and month(fecha)="01"
Estimated Cost: 4 Análisis
Estimated # of Rows Returned: 1 Se observa que la tabla inv_detalle no
1) inv_header: SEQUENTIAL SCAN tiene el indice adecuado, razón por la
Filters: (YEAR(inv_header.fecha )=2004 AND cual el SGDB elige el FULL TABLE
MONTH(inv_header.fecha )=1 ) SCAN.
(1) Index Keys: nro_tran ing_egr orden cod_tv nro_valor
Lower Index Filter: inv_detalle.nro_tran=inv_header.nro_tran
NESTED LOOP JOIN

es Previa
Descripción de Solución. PASO 3. QUERY: PASO 1.
los Pasos de
Se creo el índice en la tabla inv_header ------
Guía
Aplicación de utilizando el campo fecha. select inv_detalle.* from inv_header,inv_detalle
la Guía where inv_header.nro_tran=inv_detalle.nro_tran
Propuesta CREATE INDEX idx_inv_header1 ON
inv_header(fecha) and year(fecha)="2004" and month(fecha)="01"
Ejemplo 1.
Ejemplo 2.
Estimated Cost: 4
Ejemplo 3. Resultado. Estimated # of Rows Returned: 1

1) inv_header: SEQUENTIAL SCAN
Tiempo: 10.4 min.
Filters: (YEAR(inv_header.fecha )=2004 AND
Método de Acceso: FULL TABLE SCAN
MONTH(inv_header.fecha )=1 )
Análisis
(1) Index Keys: nro_tran ing_egr orden cod_tv nro_valor
El plan no varia ni en tiempo y ni en Lower Index Filter:
el tipo de acceso, pese a que se creo
inv_detalle.nro_tran=inv_header.nro_tran
el índice. El problema esta en la
NESTED LOOP JOIN
presencia de funciones en la cláusula
WHERE.

es Previa
QUERY: PASO 1.
Descripción de
Solución. PASO 2.
los Pasos de ------
Guía Reescribir la consulta, para que la cláusula select inv_detalle.* from inv_header,inv_detalle
Aplicación de WHERE sea SARGABLE, se utilizo la Regla 11
la Guía where inv_header.nro_tran=inv_detalle.nro_tran
del paso 2.
Propuesta
and fecha between "01/01/2004" and "31/01/2004"
Ejemplo 1.
Estimated Cost: 4
Ejemplo 2. select inv_detalle.* from inv_header,inv_detalle
Ejemplo 3.
where inv_header.nro_tran=inv_detalle.nro_tran 1) inv_header: INDEX PATH
and fecha between "01/01/2004" and "31/01/2004" (1) Index Keys: fecha
Lower Index Filter: inv_header.fecha >= 01/01/2004
Upper Index Filter: inv_header.fecha <= 31/01/2004
2) inv_detalle: INDEX PATH
Resultado.
(1) Index Keys:
Tiempo: 0.01 min.
nro_tran ing_egr orden cod_tv nro_valor
Método de Acceso: INDEX PATH Lower Index Filter: inv_detalle.nro_tran =
inv_header.nro_tran
NESTED LOOP JOIN
Conclusiones
Conclusiones
Recomendacione
Los pasos de la presente Guía proporcionan un marco de
s.
referencia para poder encarar el problema de rendimiento
de consultas SQL costosas.
Los pasos de la Guía pueden ser utilizado en cualquier
momento, porque el Proceso de Optimización es:
Dinámico, no siempre se aplica la misma solución.
Continuo, no tiene una fecha de finalización.
Impredecible, no se sabe con certeza cuando se
presentará un problema de rendimiento de consulta.
Debe primar el criterio y la experiencia para el uso de la
presente Guía.
Recomendaciones
Conclusiones
Recomendacione
El bajo rendimiento de las consultas no siempre es
s.
atribuible a la forma como fue formulada la consulta y/o
la falta índice. Otros factores pueden contribuir:
•Capacidad de Hardware reducida,
•Comunicaciones deficientes,
•Mala Configuración de la Instancia del SGBD
Utilice herramientas automatizadas para Optimizar

Consultas, como por ejemplo:
http://www.quest.com/es/
MUCHAS GRACIAS.
MUCHAS GRACIAS.
Modelo
Relacional
Lenguajes Estadísticas de la Base de Datos.
Relacional
Sistema de
Base de Datos
El Proceso de
Optimización
de Consultas
El Optimizador
de Consultas
Además, se utiliza información acerca de los índices
Volver
Modelo
Relacional
Medidas de Costos.
Lenguajes
Relacional
El costo se mide en función de la cantidad de CPU
Sistema de utilizada y de la cantidad de páginas de disco
Base de Datos
El Proceso de
rescatadas.
Optimización
de Consultas
El Optimizador
b.1. Búsqueda Lineal (Full Table Scan o Table Scan)
de Consultas
La mas costosa
b.2. Índice Primario, igualdad en la clave.
La mas eficiente
b.3. Índice Secundario, igualdad.
+/- eficiente
Volver
Modelo
Relacional
Reglas de Transformación de Expresiones.
Lenguajes Una regla de equivalencia permite transformar una expresion E1
Relacional
en la otra E2, mientras se preserva la equivalencia .
Sistema de
Base de Datos
El Proceso de
Optimización
de Consultas
El Optimizador
de Consultas
Aplicando las Reglas
Volver
Modelo
Relacional
Selección de Ordenes JOIN.
Lenguajes
Relacional
La cláusula FROM no dicta el orden en el cual las tablas deben ser
Sistema de procesadas .
Base de Datos
…FROM Tabla1, Tabla2,Tablan
El Proceso de
Optimización
de Consultas Se evalúa todas las permutaciones razonables y se estima el costo
El Optimizador
de Consultas
total en términos de tiempo de E/S.
Número de Tablas N! Método Optimizado Ahorro
6 720 504 30%
7 5040 1344 73.3%
8 40320 3024 92.5%
9 362880 6048 98.3%
10 3628800 11088 99.7%
16 20922789888000 148512 99.999%
Volver
Modelo
Relacional
Selección del Plan de Ejecución.
Lenguajes
Relacional
Sistema de
Base de Datos
El Proceso de
Optimización
de Consultas
…
El Optimizador
de Consultas
Costo1 Costo2 Coston
La selección del Plan de Ejecución Optimo, esta determinado por la

solución que tenga el menor costo estimado.
Sin embargo, NO SIEMPRE SE ELIGE EL MEJOR PLAN!!!!!!
Volver

Guía para La Optimización de Consultas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía para La Optimización de Consultas

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTONOMA GABRIEL RENE

Elaborado por: Ubaldo Pérez

Santa Cruz de la Sierra – Bolivia

• Parte I. Perfil del Proyecto.

Antecedentes En las Aplicación Productiva, existe la posibilidad de encontrar

-Elevada carga del CPU

Y por supuesto estos problemas son la causa de:

Las Consultas SQL que generan este tipo de problema, se las

Antecedentes ¿Que hacer cuando se presenta una

¿Por donde empezar?, si no se

Es así, que se propone una

Modelo El Modelo de Datos Relacional (MDR) fue propuesto por Edgar

La única herramienta de Estructura de Datos usada por este

Restricciones de Integridad sobre las Relaciones.

Modelo El Algebra Relacional: Es un lenguaje PROCEDIMENTAL, y consiste

aaa 111 234 Π A,B,X (σ X=“aa” (R1XR2)) A B X

ccc 123 234 Aplicando la bbb 222aa

σ X=“aa” 2do. Seleccionar las tuplas con X=“aa”

[GROUP BY A1, A2,...,An] // Agrupador

Ordenes Join. Optimizador

Resultado de la Motor de Plan de

No esta orientada a un SGBD en particular

La guía esta orientado a cierto de tipo de usuarios como ser:

Consideracion Paso 1. Generar el Plan de Ejecución

Full Table Scan Index Scan

Si existe un acceso FULL TABLE SCAN,

Consideracion Planes de Ejecución para diferentes SGBD.

SQL SERVER 1. SELECT statement La línea dos se indica que se utiliza el

DB/2 1. SELECT statement La línea dos indica que se utilizo el filtro

Consideracion Paso 2. Reescribir la Consulta.

SELECT DISTINCT fname SELECT fname

Consideracion Reglas para evitar escribir Consultas SQL costosas.

Consideracion Reglas para evitar escribir Consultas SQL costosas.

R9. Uso de la Cláusula UNION para Eliminar el Full Table Scan.

Consideracion Paso 3. Crear y Gestionar Índices.

Consideracion Reglas para crear índices.

R4. Evitar Valores Nulos en un Índices. Si un atributo es definido como

R5. Atributos en la cláusula ORDER BY. Si existen atributos que

Consideracion Reglas para crear índices.

Consideracion Paso 4. Ajustar el Esquema de la Base de Datos.

Consideracion Esquema de la BD Valores.

inv_detalle foreign key (nro_tran) references inv_header,

Nombre Tamaño de la tabla Numero de Filas Tamaño de la Tabla

inv_header 64 36,162 2.20

Consideracion Optimización Consulta Nro. 1.

Consideracion Optimización Consulta Nro. 1.

Consideracion Optimización Consulta Nro. 2.

Consideracion Optimización Consulta Nro. 2.

Consideracion Optimización Consulta Nro. 3.

Consideracion Optimización Consulta Nro. 3.

Ejemplo 3. Resultado. Estimated # of Rows Returned: 1

Consideracion Optimización Consulta Nro. 3.

•Mala Configuración de la Instancia del SGBD

Utilice herramientas automatizadas para Optimizar

Además, se utiliza información acerca de los índices

b.3. Índice Secundario, igualdad.

Aplicando las Reglas

6 720 504 30%

7 5040 1344 73.3%

8 40320 3024 92.5%

9 362880 6048 98.3%

10 3628800 11088 99.7%