Un Non-clustered Index es una estructura de datos auxiliar, típicamente implementada como un B-tree, que contiene un conjunto ordenado de valores de una o más columnas de una tabla, junto con punteros (Row IDs o PIDs) a las ubicaciones físicas de las filas de datos correspondientes. A diferencia de un Clustered Index, el Non-clustered Index no determina el orden físico de almacenamiento de los datos en la tabla. Los datos de la tabla permanecen en su orden original o en el orden definido por un Clustered Index si existe. Cada Non-clustered Index es una copia ordenada de las columnas indexadas y sus punteros, lo que permite búsquedas rápidas, pero requiere una operación de 'lookup' adicional para recuperar la fila completa de datos de la tabla base.
Los Non-clustered Indexes son ampliamente utilizados en sistemas de gestión de bases de datos relacionales (RDBMS) como Microsoft SQL Server, PostgreSQL, MySQL y Oracle. En SQL Server, se pueden crear múltiples Non-clustered Indexes por tabla, cada uno optimizado para diferentes patrones de consulta. PostgreSQL los implementa como B-trees por defecto, permitiendo también índices parciales y 'covering indexes' (índices que contienen todas las columnas necesarias para una consulta, evitando el acceso a la tabla base). En MySQL, tanto los motores InnoDB como MyISAM soportan Non-clustered Indexes, donde InnoDB los implementa como índices secundarios que apuntan a la clave primaria (que es el Clustered Index implícito), mientras que MyISAM apunta directamente a la dirección física de la fila.
Para un Arquitecto de Sistemas, los Non-clustered Indexes son cruciales para optimizar el rendimiento de las consultas sin imponer un único orden físico a los datos. La decisión de crearlos implica un trade-off: mejoran significativamente la velocidad de lectura para consultas específicas (SELECT, WHERE, ORDER BY, JOIN) al reducir el número de operaciones de I/O, pero añaden sobrecarga en las operaciones de escritura (INSERT, UPDATE, DELETE) ya que cada índice debe ser actualizado. Además, consumen espacio de almacenamiento adicional. Un arquitecto debe analizar los patrones de acceso a los datos, la cardinalidad de las columnas, la selectividad de las consultas y la frecuencia de las operaciones de escritura para diseñar una estrategia de indexación óptima, equilibrando el rendimiento de lectura y escritura y el uso de recursos. Un exceso de índices puede degradar el rendimiento general, mientras que la falta de ellos puede llevar a consultas lentas y costosas.