Para las consultas que involucran pequeñas porciones de las filas de la tabla, los índices siempre son beneficiosos, ya sea 100 filas o 1,000,000.
Ver esta entrada en mi blog para ejemplos con los planes y detalles de rendimiento:
Las consultas como esta:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
muy probablemente utilizará HASH JOIN. Se generará una tabla hash para la tabla más pequeña, y las filas de la tabla más grande se usarán para sondear la tabla hash.
Para hacer esto, no se necesita ningún índice.
Sin embargo, esta consulta:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
WHERE t1.othercol = @value
utilizará NESTED LOOPS: las filas de la tabla exterior (table1) será buscado utilizando un índice en table1.othercol, y las filas de la tabla interna (table2) será buscado utilizando un índice en table2.col.
Si no tiene un índice en col1, se usará un HASH JOIN que requiere escanear todas las filas de ambas tablas y algunos recursos adicionales para construir una tabla hash.
índices también son útiles para las consultas como esta:
SELECT t2.col
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
, en cuyo caso el motor no necesita leer table2 sí en absoluto: eveything que necesita para esta consulta se puede encontrar en el índice , que puede ser mucho más pequeño que la tabla en sí y más eficiente de leer.
Y, por supuesto, si es necesario ordenar los datos y tienen índices en tanto table1.col y table2.col, a continuación, la siguiente consulta:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
ORDER BY
t2.col
probablemente utilizará MERGE JOIN método, que es súper rápido si ambos conjuntos de filas de entrada están ordenados y su salida también está ordenada, lo que significa que ORDER BY es gratuito.
Tenga en cuenta que incluso si no tiene un índice, un optimizador puede elegir Eager Spool su tabla pequeña, lo que significa crear un índice temporal para la duración de la consulta y descartar el índice una vez que finalice la consulta.
Si la consulta es pequeña, será muy rápido, pero de nuevo, un índice no dolerá (para las consultas de SELECT, me refiero). Si el optimizador no lo necesita, simplemente no se usará.
Tenga en cuenta, sin embargo, que la creación de un índice puede afectar el rendimiento DML, pero es otra historia.
En realidad, la base de datos no ordena las claves en una sola página. Hasta que llegue más allá de ese punto, no hay beneficio. Y probablemente por varias páginas más allá de eso. – dkretz
@Robert: también se benefician cuando usa solo las columnas indexadas en la consulta o cuando necesita ordenar los datos. Y no, no siempre son un beneficio en la cláusula WHERE, solo en las muy selectivas. – Quassnoi
Quassnoi, vi tu publicación en el blog. Para que lo sepas, la decisión final de indexar nuestra base de datos (basada en información adicional en esta publicación: stackoverflow.com/questions/1033796/...) fue indexar todas las claves externas EXCEPTO las que participan en combinaciones de tablas de búsqueda que contienen MENOS DE 10 ARCHIVOS. –