sql - una - uso de indices en oracle

¿Cuándo debería considerar indexar sus tablas sql? (8)

¿Cuántos registros debería haber antes de considerar la indexación de mis tablas sql?

Como rutina, realizo lo siguiente en tablas pesadas de lectura :

Cree índices en campos comunes de unión como Foreign Keys cuando creo la tabla.
Compruebe el plan de consulta de Vistas o Procedimientos almacenados y agregue índices siempre que se indique un escaneo de tabla .
Compruebe el plan de consultas para consultas de mi aplicación y agregue índices siempre que se indique una exploración de tabla. (y a menudo intenta convertirlos en procedimientos almacenados)

En tablas pesadas de escritura (como registros de actividad) evito los índices a menos que sean absolutamente necesarios. También tiendo a archivar esos datos en tablas indexadas a intervalos regulares.

Crearía las entradas de índice cuando creara mi tabla. Si decide crear índices después de que la tabla haya crecido a 100, 1000, 100000 entradas, puede tomar mucho tiempo y tal vez hacer que su base de datos no esté disponible mientras lo está haciendo.

Primero piense en la tabla, cree los índices que cree que necesitará y luego continúe.

En algunos casos, descubrirá que debe haber indexado una columna, si ese es el caso, corríjala cuando la descubra.

Crear un índice en un campo buscado no es una pre-optimización, es solo lo que se debe hacer.

Cuando el tiempo de consulta es inaceptable. Mejor aún, cree algunos índices ahora que probablemente sean útiles, y ejecute EXPLAIN o EXPLAIN ANALYZE en sus consultas una vez que su base de datos esté poblada por datos representativos. Si los índices no ayudan, elimínelos. Si hay consultas lentas que podrían beneficiarse de más índices o más, cambie los índices.

No va a estar bloqueado en una elección inicial de índices. ¡Experimenta y asegúrate de medir el rendimiento !

Depende.

¿Cuantos datos hay en la tabla? ¿Con qué frecuencia se insertan los datos? Muchos índices pueden ralentizar el tiempo de inserción. ¿Siempre consultas todas las filas de la tabla? En este caso, los índices probablemente no ayudarán mucho.

Sin embargo, esos no son usos comunes. En la mayoría de los casos, usted sabe que va a consultar un subconjunto de datos. EN QUE campos? ¿Hay campos comunes a los que siempre se les une? Mire los planes de consulta para consultas comunes o típicas, generalmente le mostrará dónde está gastando todo su tiempo.

Dos.

Lo digo en serio. Si ahora hay dos filas, y siempre habrá dos filas, el costo de la indexación es casi cero. Es más rápido indexar que reflexionar si deberías. No le tomará mucho tiempo al optimizador descubrir que escanear la tabla es más rápido que usar el índice.

Si hay dos filas ahora, pero habrá 200,000 en el futuro cercano, el costo de no indexar podría llegar a ser prohibitivamente alto. El momento adecuado para considerar la indexación es ahora.

Habiendo dicho esto, recuerde que obtiene un índice automáticamente cuando declara una clave principal. Crear una tabla sin clave principal es un problema en la mayoría de los casos. Entonces, la única vez que realmente necesita considerar la indexación es cuando quiere un índice que no sea el índice en la clave principal. Necesita conocer el tráfico y el volumen anticipado para realizar esta llamada. Si lo hace mal, lo sabrá y puede revertir la decisión.

Una vez vi una tabla de referencia que se había creado sin índice cuando contenía 20 filas. Debido a un cambio en el negocio, esta tabla había crecido a aproximadamente 900 filas, pero la persona que debería haber notado la ausencia de un índice no lo hizo. El tiempo para insertar una nueva orden aumentó de aproximadamente 10 segundos a 15 minutos.

En general, estoy de acuerdo con el consejo anterior. Declare siempre la integridad referencial para las tablas (clave principal, claves externas), restricciones de columna (no nulo, verificación). Le ahorra pesadillas cuando las aplicaciones ponen datos incorrectos en las tablas (incluso en desarrollo). También consideraría agregar índices para las columnas de acceso común (columnas en sus cláusulas where que se usan en las pruebas =, <>). La mayoría de las implementaciones RDBMS modernas son bastante buenas para mantener tus índices actualizados, sin afectar tu rendimiento. Entonces, el costo de tener índices es mínimo. Además, la mayoría de los RDBMS tienen evaluadores de planes de consulta que analizan los costos relativos que van a las filas de datos a través del índice, o usan algún tipo de escaneo de tabla. Entonces, una vez más los éxitos de rendimiento son mínimos.

No hay una buena razón para renunciar a los índices obvios (FK, etc.) cuando está creando la tabla. Nunca afectará notablemente el rendimiento al tener índices innecesarios en tablas pequeñas, y es bueno dar un primer corte cuando tu mente está en el diseño del esquema. Además, algunos índices sirven para evitar duplicados, que pueden ser útiles independientemente del tamaño de la tabla.

Supongo que la respuesta correcta a su pregunta es que el número de registros en la tabla no debería tener nada que ver con cuándo crear índices.

Si hay una restricción única en la tabla (y debe haber al menos una), entonces generalmente se aplicará por un índice único.

De lo contrario, agregará índices cuando el rendimiento de la consulta sea malo y la adición del índice mejorará de manera demostrable el rendimiento. Hay libros sobre el tema de cómo crear buenos conjuntos de índices en tablas, incluido el Diseño del índice de base de datos relacional y los Optimizadores . Le dará muchas ideas y las razones por las que son buenas.

Ver también:

y, sin duda, una multitud de otros.