Solución:
Es difícil imaginar escenarios del mundo real en los que sea útil indexar cada columna, por las razones mencionadas anteriormente. El tipo de escenario requeriría un montón de consultas diferentes, todas accediendo exactamente a una columna de la tabla. Cada consulta podría acceder a una columna diferente.
Las otras respuestas no abordan los problemas durante el Seleccione lado de la consulta. Obviamente, mantener índices es un problema, pero si está creando las tablas una vez y luego leyendo muchas, muchas veces, la sobrecarga de actualizaciones / inserciones / eliminaciones no es una consideración.
Un índice contiene los datos originales junto con puntos a registros / páginas donde residen los datos. La estructura de un índice hace que sea rápido para hacer cosas como: encontrar un valor único, recuperar valores en orden, contar el número de valores distintos y encontrar los valores mínimo y máximo.
Un índice no solo ocupa espacio en el disco. Más importante aún, ocupa la memoria. Y la contención de la memoria suele ser el factor que determina el rendimiento de las consultas. En general, construir un índice en cada columna ocupará más espacio que los datos originales. (Una excepción sería una columna que es relativamente ancha y tiene relativamente pocos valores).
Además, para satisfacer muchas consultas, es posible que necesite uno o más índices más los datos originales. La caché de su página se llena bastante de datos, lo que puede aumentar la cantidad de pérdidas de caché, lo que a su vez genera más gastos generales.
Me pregunto si su pregunta es realmente una señal de que no ha modelado adecuadamente sus estructuras de datos. Hay algunos casos en los que desea que los usuarios creen tablas permanentes ad hoc. Por lo general, sus datos se almacenarían en un formato predefinido, que puede optimizar para los requisitos de acceso.
No, porque debe tener en cuenta que cada vez que agrega o actualiza un registro, debe recalcular sus índices y tener índices en todas las columnas tomaría mucho tiempo y conduciría a un mal desempeño.
Entonces, las bases de datos como los almacenes de datos donde solo se usan consultas seleccionadas es una buena idea, pero en una base de datos normal es una mala idea.
Además, no es porque esté usando una columna en una cláusula where que tenga que agregar un índice en ella. Intente encontrar una columna en la que el registro sea casi todo único, como una clave principal, y que no edite con frecuencia. Una mala idea sería indexar el sexo de una persona porque solo hay 2 valores posibles y el resultado del índice solo dividirá los datos y luego buscará en casi todos los registros.
No, no debe indexar todas sus columnas, y hay varias razones para esto:
- Existe un costo para mantener cada índice durante una declaración de inserción, actualización o eliminación, que hará que cada una de esas transacciones demore más.
- Aumentará el almacenamiento requerido ya que cada índice ocupa espacio en el disco.
- Si los valores de la columna no están dispersos, el índice no se utilizará / ignorará (por ejemplo, una marca de género).
- Los índices compuestos (índices con más de una columna) pueden beneficiar enormemente el rendimiento de las cláusulas WHERE, GROUP BY, ORDER BY o JOIN que se ejecutan con frecuencia, y no se pueden combinar varios índices únicos.
Es mucho mejor usar planes de Explicación y acceso a datos y agregar índices cuando sea necesario (y solo cuando sea necesario, en mi humilde opinión), en lugar de crearlos todos por adelantado.