Quiero agregar aquí que diferentes bases de datos requieren diferentes estrategias. Comparemos MySQL con InnoDB y PostgreSQL, por ejemplo.
InnoDB
Las tablas de InnoDB son básicamente un índice de árbol b de la clave primaria que se extienden para incluir la información de fila en la entrada de índice. Los escaneos de orden físico no son compatibles y todos los escaneos ocurren en orden lógico. Esto significa dos cosas:
Una exploración secuencial en Innodb genera una gran cantidad de E / S de disco aleatorias , y
El índice de clave principal debe atravesarse independientemente de si se está utilizando un índice secundario.
Las búsquedas de claves principales son más rápidas en este modelo que en cualquier otro enfoque.
En este caso, es muy importante indexar suficientes campos en tablas de varias páginas. La regla típica es indexar todo lo que desea filtrar.
PostgreSQL
PostgreSQL usa archivos de montón, una tabla por archivo (algunas tablas pueden ser muchos archivos) donde las tuplas se asignan desde el espacio libre de ese montón. Se admiten exploraciones de orden físico. Para que funcione un escaneo de orden lógico, se debe agregar un índice.
Las claves primarias en PostgreSQL son básicamente un subconjunto de índices únicos donde ningún valor puede ser NULL. Las restricciones ÚNICAS se realizan mediante índices implícitos, y se admiten varios otros tipos de índice con diferentes operaciones posibles en el índice.
Esto significa:
Búsquedas de claves primarias, suponiendo que una tabla razonablemente grande requiere golpear un archivo de índice y un archivo de tabla. Esto es significativamente más lento que el enfoque de MySQL donde el índice solo debe atravesarse y la fila está contenida en el índice.
Los escaneos de orden físico funcionan mucho mejor, reduciendo la E / S de disco aleatorio donde se procesarán cantidades significativas de filas.
Los escaneos de índice secundario funcionan mejor que MySQL porque solo se debe atravesar un índice para llegar a la parte física de la tabla.
En este modelo, los índices son a menudo necesarios, pero el planificador tiene más libertad para usar un índice, y las implicaciones de no usar uno son a menudo menos severas. Las tablas están optimizadas de manera más general (en lugar de especializarse en búsquedas pkey) y, por lo tanto, se requieren menos índices.
TL; DR
Conoce tu RDBMS.