No sé acerca de las partes internas de Microsoft SQL Server, pero puedo responder por MySQL, que etiquetó para su pregunta. Los detalles pueden variar para otras implementaciones.
P1. Correcto, no se necesita espacio adicional para el índice agrupado.
¿Qué sucede si elimina el índice agrupado? El motor InnoDB de MySQL siempre usa la clave principal (o la primera clave única no nula) como índice agrupado. Si define una tabla sin una clave principal o elimina la clave principal de una tabla existente, InnoDB genera una clave artificial interna para el índice agrupado . Esta clave interna no tiene una columna lógica para hacer referencia a ella.
P2. No se garantiza un orden de filas devuelto por una consulta que utiliza un índice no agrupado. En la práctica, es el orden en que se accedió a las filas. Si necesita que las filas se devuelvan en un orden específico, debe usar ORDER BY en tu consulta Si el optimizador puede inferir que su orden deseado es el mismo que el orden en el que accederá a las filas (orden de índice, ya sea por índice agrupado o no agrupado), entonces puede omitir el paso de clasificación.
P3. El índice no agrupado de InnoDB no tiene un puntero a la fila correspondiente en una hoja del índice, tiene el valor de la clave primaria. Entonces, una búsqueda en un índice no agrupado es en realidad dos búsquedas de árbol B, la primera para encontrar la hoja del índice no agrupado y luego una segunda búsqueda en el índice agrupado.
Esto es el doble del costo de una sola búsqueda de árbol B (más o menos), por lo que InnoDB tiene una función adicional llamada Índice de hash adaptativo . Los valores buscados con frecuencia se almacenan en caché en el AHI, y la próxima vez que una consulta busque un valor en caché, puede realizar una búsqueda O(1). En la memoria caché AHI, encuentra un puntero directamente a la hoja del índice agrupado, por lo que elimina ambos Búsquedas de árboles B, parte del tiempo.
La medida en que esto mejora el rendimiento total depende de la frecuencia con la que busque los mismos valores que se han buscado anteriormente. En mi experiencia, es típico que la proporción de búsquedas hash frente a búsquedas no hash sea de aproximadamente 1:2.
P4. Construya los índices para atender las consultas que necesita optimizar. Por lo general, un índice agrupado es una clave principal o única y, al menos en el caso de InnoDB, esto es obligatorio. Ni age ni salary es probable que sea único.
Puede que le guste mi presentación, Cómo diseñar índices, de verdad .
P5. InnoDB crea automáticamente un índice cuando declara una restricción única. No puede tener la restricción sin que exista un índice para ella. Si no tuviera un índice, ¿cómo garantizaría el motor la unicidad al insertar un valor? Tendría que buscar en toda la tabla un valor duplicado en esa columna. El índice ayuda a que las comprobaciones únicas sean mucho más eficientes.
