de Martin LE TARNEC.

Los desarrolladores necesitan indexar


Los problemas de rendimiento en SQL (Structured Query Language) son tan antiguos como este lenguaje. Algunas personas dicen que SQL es lento por definición. Aunque eso era cierto al inicio de la creación del lenguaje, ya no es cierto hoy en día. Sin embargo, los problemas de rendimiento SQL son todavía comunes. ¿Y eso por qué es así?

El lenguaje SQL es quizás el más exitoso de entre los de cuarta generación (4GL). Su principal ventaja es su capacidad para separar qué es y quién es . Una sentencia SQL es una descripción estructurada de qué es lo que se necesita, sin tener que especificar instrucciones de cómo puede ser ejecutado. A modo de ejemplo:

SELECT date_of_birth
  FROM employees
 WHERE last_name = 'WINAND'

Esta sentencia SQL se lee como una sentencia en inglés para explicar el resultado de los datos obtenidos. Para escribir una sentencia SQL no se requiere ningún tipo de conocimiento a cerca del funcionamiento interno de la base de datos o del almacenamiento del sistema (como discos o archivos). No existe la necesidad de decir a la base de datos qué archivo debe abrir ni cómo ha de hacerlo para encontrar los registros solicitados. Muchos desarrolladores tienen años de experiencia desarrollando sentencias SQL, a pesar de contar con un conocimiento muy limitado del mecanismo interno de la base de datos.

La separación los conceptos "lo que se necesita" y "cómo hacerlo" funciona muy bien en SQL, pero no es perfecta. La abstracción alcanza su límite cuando llega el rendimiento: el autor de una sentencia SQL por definición no se preocupa por cómo la base de datos ejecutará la sentencia. En consecuencia, se dice que el autor no es responsable de la ejecución lenta. Sin embargo, la experiencia demuestra lo contrario: el autor debe saber un poco a cerca de la base de datos para prevenir problemas de rendimiento.

En realidad, la única cosa que los desarrolladores deben aprender es a indexar. La indexación de una base de datos es, de hecho, una tarea de programación. Así que la información más importante para indexar de manera correcta no es la configuración del almacenamiento del sistema ni tampoco la instalación del hardware. La información más importante para indexar es como la aplicación selecciona los datos. Este conocimiento sobre "el acceso a los datos" no resulta muy sencillo para los administradores de bases de datos (DBA) o consultores externos. Algunas veces se requiere más información a través de la ingeniería inversa de la aplicación. En comparación, el equipo de desarrollo, si que dispone de toda la información.

Este libro cubre todo lo que debe saber un desarrollador sobre los índices y nada más. Para ser más preciso, el libro profundiza en un tipo de índices, el más importante de todos: el índice B-tree.

El índice B-tree trabaja de manera similar en muchas base de datos. Este libro emplea solamente la terminología de las bases de datos Oracle, pero el concepto se aplica a las demás bases de datos sin problema. Las notas al pie de página proveen información relevante para MySQL, PostgreSQL y SQL Server®.

La estructura del libro está perfectamente adaptada para los desarrolladores. Por otra parte, muchos capítulos se refieren a una parte específica de una sentencia SQL.

CAPÍTULO 1 - Anatomía de un índice

El primer capítulo es el único que no trata solamente de SQL; aborda los fundamentos de la estructura de un índice. Una explicación de la estructura de un índice es fundamental para los siguientes capítulos "¡No se debe dejar de leer!"

Aunque el capítulo es breve y solamente tiene ocho páginas después de trabajar sobre él, se podrá entender el fenómeno de los índices lentos.

CAPÍTULO 2 - El filtro where

Es donde se abordan todos los puntos bloqueadores. El capítulo explica todos los aspectos del comando where, desde ejemplos muy fáciles de columna sencilla hasta filtros muy complejos para rangos y casos especiales como LIKE.

Este capítulo constituye el cuerpo principal del libro. Después de haberlo leído, se podrán usar esas técnicas y escribir sentencias SQL optimizadas.

CAPÍTULO 3 - Rendimiento y escalabilidad

Este capítulo es una pequeña aclaración a cerca del rendimiento y la escabilidad de las base de datos. Permitirá entender que agregar hardware no es la mejor solución para las sentencias lentas.

CAPÍTULO 4 - La operación de unión (JOIN)

Regresando al SQL: aquí se podrá encontrar la explicación de cómo usar los índices para mejorar las uniones de tablas.

CAPÍTULO 5 - Agrupación de datos

¿Hay diferencias entre seleccionar una sola columna o todas las columnas? Este capítulo ofrecerá la respuesta con un truco para obtener un rendimiento mejor.

CAPÍTULO 6 - Ordenamiento y agrupación

Incluso order by y group by pueden usar índices.

CAPÍTULO 7 - Resultados parciales

Este capítulo explica cómo sacar provecho de la ejecución por fases; para casos en los que no se necesita todo el conjunto de datos.

CAPÍTULO 8 - Insert, delete y update

¿Cómo afectan los índices al rendimiento de las escrituras? Los índices no salen gratis! ¡Úsalos sabiamente!

APÉNDICE A - Planes de ejecución

Pregunta a la base de datos cómo se está ejecutando la sentencia

APÉNDICE B - Listado de mitos

Se trata de una lista los falsos mitos más comunes y una explicación de la realidad. El listado aumenta conforme el libro crece.

APÉNDICE C - Esquemas de ejemplo

Todos las sentencias create e insert para las tablas de este libro.

Enlaces

Presentación de la charla Índices: el rendimiento desatendido polifacético

Acerca del autor

Foto de Markus Winand

Markus Winand enseña eficientemente SQL, en casa y online. Minimiza el tiempo de desarrollo utilizando moderno SQL y optimiza el tiempo de ejecución con indexación inteligente. Para ello también ha publicado el libro SQL Performance Explained.

“Use The Index, Luke” de Markus Winand se halla bajo licencia Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Aspectos legales | Contacto | SIN GARANTÍA | Marcas | Privacy | CC-BY-NC-ND 3.0 licencia