La mayoría de nosotros probablemente esté de acuerdo en que usar índices de bases de datos es bueno. Demasiados índices y rendimiento en realidad pueden degradarse.
Como regla general, ¿qué campos deben indexarse?
¿Qué campos no deben indexarse?
¿Cuáles son las reglas para usar índices mientras se logra un equilibrio entre demasiados índices y no suficientes para lograr mejoras de rendimiento, no degradación?
Respuestas:
Corto
Creo que la regla de "demasiados índices" es un poco engañosa.
Largo
Dado que la base de datos promedio es de alrededor del 98%, las lecturas (o más) necesitan ser optimizadas. INSERT es una lectura si hay un índice único, por ejemplo. O el DÓNDE en una actualización. Una vez leí que incluso una base de datos de escritura intensiva sigue siendo 85% de lecturas.
Lo que sí tiene es una indexación de baja calidad. Ejemplos:
cold, coleycold, cole, colf)Tenga en cuenta que es bastante típico tener índices varias veces más grandes que sus datos reales incluso en sistemas OLTP.
En general, comenzaría con el
Entonces miraría:
Dicho esto, he roto estas reglas para algunos sistemas después de ver cómo se resolvieron las cosas (10 mil millones de filas más tarde) para ajustar un sistema. Pero nunca consideraría no indexar a menos que pudiera demostrar por qué lo estoy haciendo.
fuente
Debe perfilar el uso y la carga de su base de datos e identificar cuellos de botella debido a la falta de índices, o debido a demasiados índices. Luego debe elegir el índice adecuado, y eso requiere un buen conocimiento de las técnicas específicas de indexación de la base de datos.
fuente
Simplemente una de las mejores series de artículos escritos sobre qué índices elegir y por qué sería de Gail Shaw. Puede encontrar los artículos haciendo clic aquí.
La pregunta que haces puede responderse de 50 maneras diferentes. Realmente todo se reduce a los datos que tiene y cómo se consultarán. Una regla general es que siempre debe tener un índice agrupado en cada tabla para evitar montones. Los índices agrupados generalmente deberían ser lo más pequeños posible. Si la tabla tiene un índice agrupado, todos los registros de índice en las páginas de hoja del índice no agrupado almacenarán el valor de registro del índice agrupado respectivo para búsquedas de marcadores. Si una tabla es un montón, SQL creará un identificador único para las búsquedas de marcadores. No recuerdo el tamaño de 8 o 16 bytes. Esto podría terminar siendo un tipo de datos mucho más grande que decir un INT. Imagine tener 8 índices no agrupados en una tabla de montón.
fuente
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.
fuente
De la Guía de conceptos de Oracle 11.2:
De la Guía de ajuste de rendimiento 11.2:
De la Guía del administrador 11.2:
fuente
Incluso con todos los enlaces anteriores, debe ver lo que Kimberly Tripp ha escrito sobre el cuidado, la alimentación y el uso de índices.
Para empezar, siga este enlace a la colección de publicaciones de blog relacionadas con el índice de Kimberly. Puede explorar temas específicos utilizando los widgets "En esta página" y "Categorías" en el lado izquierdo de la ventana de su navegador.
Aquí hay mucha información, pero no te desanimes.
La página Acerca de Kimberly está aquí
fuente
Aquí hay algunos recursos más que pueden resultarle útiles si está trabajando con SQL Server:
fuente