¿Qué significa "índice" en los RDBMS? [cerrado]

Utilizo índices como lo hacen la mayoría de los desarrolladores (principalmente en ... ¡bueno! Índice), pero estoy seguro de que hay muchas formas sutiles de optimizar una base de datos utilizando el índice. No estoy seguro de si es específico de cualquier implementación de un DBMS.

Mi pregunta es: ¿cuáles son buenos ejemplos de cómo usar el índice (excepto en casos básicos y obvios) y cómo un DBMS optimiza su base de datos cuando especifica un índice en una tabla?

Piense en un índice como "tabla de contenido" ... que es una lista ordenada de punteros a posiciones en un archivo, también conocido como compensaciones. Supongamos que tiene millones de registros almacenados en una tabla, en lugar de buscar criterios coincidentes en la tabla, es mucho más rápido hacer referencia a una lista ordenada de coincidencias, luego apilar los punteros a las filas coincidentes específicas. Un ejemplo perfecto de un índice es un campo de clave primaria de tablas, más típicamente su campo "id". Si desea la ID de fila # 11234566, es mucho más rápido pedirle al índice un puntero a los datos que escanear la fuente de datos para la posición 11234566.

Aquí hay un uso no tan obvio de la indexación:

CREATE TABLE activity_log (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
activity_type_id SMALLINT UNSIGNED NOT NULL,
datetime_created DATETIME
KEY(activity_type_id),
PRIMARY KEY(id)
);
CREATE TABLE activity_log_to_date_key (
activity_log_id INT UNSIGNED NOT NULL,
date_created_key  INT UNSIGNED NOT NULL REFERENCES dim_datetime(id),
UNIQUE KEY(activity_log_id),
KEY(date_created_key)
);
CREATE TABLE dim_datetime (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
date_hour DATETIME NOT NULL,
PRIMARY KEY(id),
KEY(date_hour)
);

Su operación puede crear su registro de registro, pero luego crear una referencia a una fecha y hora indexada que sea más rápida de buscar / ordenar que su tabla de registro. Luego, vuelva a unir su tabla de registro en su propia clave principal. Si necesita que amplíe esto, hágamelo saber. Espero que esto tenga sentido.

Consulta de muestra:

SELECT a.activity_log_id, al.activity_type_id, al.datetime_created
FROM activity_log_to_date_key a 
INNER JOIN dim_datetime d ON (d.id = a.date_created_key)
LEFT JOIN activity_log al ON (al.id = a.activity_log_id)
WHERE d.date_hour BETWEEN '2009-01-01 00:00:00' AND '2009-06-01 12:00:00';

Un punto que mucha gente parece pasar por alto es que un DBMS a menudo (o solo puede) usar solo un índice por referencia de tabla en una consulta, y si puede y usa múltiples índices, probablemente sería más rápido usar un combinado índice si está presente.

Por ejemplo, si busca filas en una tabla grande, WHERE AnIntegerColumn = 42 AND AnOtherInt = 69la ruta más rápida hacia esas filas sería un índice en las dos columnas AnIntegerColumn y AnOtherInt. Si solo tiene un índice en cada uno individualmente pero no tiene un índice combinado, el DB buscará uno u otro índice y filtrará por separado los resultados con la segunda cláusula, o escaneará ambos y unirá los resultados después.

Otra operación simple común que se puede mejorar con índices compuestos es WHERE SomeColumn = <SomeValue> ORDER BY SomeOtherColumn: si hay un índice en SomeColumn y SomeOtherColumn (en el orden correcto), las operaciones de filtrado y ordenación pueden realizarse al mismo tiempo en algunas circunstancias.

Por supuesto, agregar demasiados índices puede ser una mala optimización, ya que el espacio adicional utilizado para almacenar los índices (y la carga de E / S para mantenerlos si su DB ve muchas operaciones de escritura) puede ser un problema peor que las consultas de lectura ligeramente menos óptimas , así que no lo hagas en exceso.

David y Randy tienen esto cubierto. Solo quería agregar que el EXPLAINcomando puede ser de gran ayuda para determinar cuándo obtendrá un gran ahorro al crear un índice, así como para sugerir qué índices son necesarios. Mostrará los pasos que la base de datos está tomando para ejecutar su consulta, de modo que sepa qué bits están tardando más.

Algo que aún no he mencionado aquí es que cuando tienes más de un disco, probablemente quieras poner tu índice en un disco diferente de donde están realmente los datos. Esto puede acelerar algunas operaciones. Creo que esto merece una pregunta por derecho propio.