sql-server - ver - uso de indices en oracle

¿Qué columnas generalmente son buenos índices? (12)

Como seguimiento de " ¿Qué son los índices y cómo puedo usarlos para optimizar las consultas en mi base de datos? ", Donde intento conocer los índices, ¿qué columnas son buenos candidatos para el índice? Específicamente para una base de datos MS SQL?

Después de buscar en Google, todo lo que he leído sugiere que las columnas que son generalmente crecientes y únicas hacen un buen índice (cosas como auto_increment de MySQL), entiendo esto, pero estoy usando MS SQL y estoy usando GUID para claves primarias, por lo que parece esos índices no beneficiarían las columnas GUID ...

Algunas personas respondieron una pregunta similar aquí: ¿cómo sabes qué es un buen índice?

Básicamente, realmente depende de cómo va a consultar sus datos. Desea un índice que identifique rápidamente un pequeño subconjunto de su conjunto de datos que sea relevante para una consulta. Si nunca consulta por fecha, no necesita un índice, incluso si es mayormente único. Si todo lo que haces es obtener eventos que ocurrieron en un cierto rango de fechas, definitivamente quieres uno. En la mayoría de los casos, un índice de género no tiene sentido, pero si todo lo que hace es obtener estadísticas sobre todos los hombres, y por separado, sobre todas las mujeres, podría valer la pena crear una. Averigüe cuáles serán sus patrones de consulta, y acceda a qué parámetro reduce al máximo el espacio de búsqueda, y ese es su mejor índice.

También considere el tipo de índice que hace: los árboles B son buenos para la mayoría de las cosas y permiten consultas de rango, pero los índices hash lo llevan directo al punto (pero no permiten rangos). Otros tipos de índices tienen otros pros y contras.

¡Buena suerte!

Debería ser aún más rápido si está usando un GUID. Supongamos que tiene los registros

100
200
3000
....

Si tiene un índice (búsqueda binaria, puede encontrar la ubicación física del registro que está buscando en el tiempo O (lg n), en lugar de buscar O (n) secuencialmente. Esto se debe a que no sabe qué registros tiene en tu mesa

El mejor índice depende del contenido de la tabla y de lo que intenta lograr.

Tomó un ejemplo Una base de datos de miembros con una Clave principal de miembros Seguridad social Numnber. Elegimos la SS porque la pría de la aplicación se refiere a la persona de esta manera, pero también desea crear una función de búsqueda que utilizará el nombre y apellido de los miembros. Entonces sugeriría crear un índice sobre esos dos campos.

Primero debe averiguar qué datos va a consultar y luego determinar qué datos necesita indexar.

En general (no uso mssql, así que no puedo comentar específicamente), las claves principales son buenos índices. Son únicos y deben tener un valor especificado. (Además, las claves principales generan índices tan buenos que normalmente tienen un índice creado automáticamente).

Un índice es efectivamente una copia de la columna que se ha ordenado para permitir la búsqueda binaria (que es mucho más rápida que la búsqueda lineal). Los sistemas de bases de datos pueden usar varios trucos para acelerar la búsqueda aún más, particularmente si los datos son más complejos que un simple número.

Mi sugerencia sería no usar ningún índice inicialmente y perfilar sus consultas. Si una consulta en particular (como buscar personas por apellido, por ejemplo) se ejecuta con mucha frecuencia, intente crear un índice sobre los atributos y el perfil relevantes nuevamente. Si hay una notable aceleración en las consultas y una desaceleración insignificante en las inserciones y actualizaciones, conserve el índice.

(Disculpas si repito cosas mencionadas en tu otra pregunta, no me había encontrado con anterioridad).

La vieja regla general eran las columnas que se utilizan mucho en las cláusulas WHERE, ORDER BY y GROUP BY, o cualquiera que pareciera ser utilizado en las uniones con frecuencia. Tenga en cuenta que me refiero a índices, NO clave principal

No dar una respuesta ''vainilla-ish'', pero realmente depende de cómo está accediendo a los datos

Los índices pueden desempeñar un papel importante en la optimización de consultas y en la búsqueda de resultados rápidamente desde las tablas. Por lo tanto, es el paso más importante seleccionar las columnas que se indexarán. Hay dos lugares principales en los que podemos considerar la indexación: las columnas a las que se hace referencia en la cláusula WHERE y las columnas utilizadas en las cláusulas JOIN. En resumen, tales columnas deben estar indexadas con respecto a las cuales debe buscar registros particulares. Supongamos que tenemos una tabla llamada compradores donde la consulta SELECT usa índices como los siguientes:

SELECT buyer_id /* no need to index */ FROM buyers WHERE first_name=''Tariq'' /* consider to use index */ AND last_name=''Iqbal'' /* consider to use index */

Dado que se hace referencia a "buyer_id" en la parte SELECT, MySQL no lo usará para limitar las filas elegidas. Por lo tanto, no hay una gran necesidad de indexarlo. El siguiente es otro ejemplo poco diferente del anterior:

SELECT buyers.buyer_id, /* no need to index */ country.name /* no need to index */ FROM buyers LEFT JOIN country ON buyers.country_id=country.country_id /* consider to use index */ WHERE first_name=''Tariq'' /* consider to use index */ AND last_name=''Iqbal'' /* consider to use index */

De acuerdo con las consultas anteriores, las columnas first_name, last_name pueden indexarse ya que están ubicadas en la cláusula WHERE. También un campo adicional, country_id de la tabla de país, se puede considerar para la indexación porque está en una cláusula JOIN. De modo que la indexación se puede considerar en cada campo en la cláusula WHERE o en una cláusula JOIN.

La siguiente lista también ofrece algunos consejos que siempre debe tener en cuenta cuando desee crear índices en sus tablas:

Solo indexe las columnas que se requieren en las cláusulas WHERE y ORDER BY. Las columnas de indexación en abundancia darán lugar a algunas desventajas.
Intente aprovechar el beneficio de la característica "índice prefijo" o "índice de columnas múltiples" de MySQL. Si crea un índice como INDEX (first_name, last_name), no cree INDEX (first_name). Sin embargo, "prefijo de índice" o "índice de múltiples columnas" no se recomienda en todos los casos de búsqueda.
Utilice el atributo NOT NULL para las columnas en las que considera la indexación, de modo que los valores NULL nunca se almacenen.
Use la opción --log-long-format para registrar consultas que no usan índices. De esta manera, puede examinar este archivo de registro y ajustar sus consultas en consecuencia.
La instrucción EXPLAIN te ayuda a revelar cómo MySQL ejecutará una consulta. Muestra cómo y en qué orden se unen las tablas. Esto puede ser muy útil para determinar cómo escribir consultas optimizadas y si las columnas son necesarias para indexar.

Actualización (23 de febrero de 2015):

Cualquier índice (bueno / malo) aumenta el tiempo de inserción y actualización.

Según sus índices (número de índices y tipo), se busca el resultado. Si su tiempo de búsqueda va a aumentar debido al índice, entonces ese es un índice malo.

Probablemente en cualquier libro, "Página de índice" podría tener la página de inicio del capítulo, el número de página del tema comienza, también comienza la página del tema secundario. Algunas aclaraciones en la página Índice ayudan, pero un índice más detallado puede confundirlo o asustarlo. Los índices también tienen memoria.

La selección del índice debe ser sabia. Tenga en cuenta que no todas las columnas requieren índice.

Los tipos de datos numéricos que se ordenan en orden ascendente o descendente son buenos índices por varias razones. Primero, los números son generalmente más rápidos de evaluar que las cadenas (varchar, char, nvarchar, etc.). En segundo lugar, si sus valores no están ordenados, puede ser necesario barajar filas y / o páginas para actualizar su índice. Eso es una carga adicional.

Si está utilizando SQL Server 2005 y se establece usando uniqueidentifiers (guids), y NO necesita que sean de naturaleza aleatoria, consulte el tipo de identificador único secuencial.

Por último, si hablamos de índices agrupados, estamos hablando del tipo de datos físicos. Si tiene una cadena como su índice agrupado, podría ponerse feo.

Realmente depende de tus consultas. Por ejemplo, si casi solo escribe en una tabla, es mejor no tener ningún índice, simplemente ralentizan las escrituras y nunca se usan. Cualquier columna que esté utilizando para unirse a otra tabla es un buen candidato para un índice.

Además, lea sobre la característica Índices perdidos. Supervisa las consultas reales que se utilizan en su base de datos y puede indicarle qué índices habrían mejorado el rendimiento.

Se debe indexar cualquier columna que se use regularmente para extraer datos de la tabla.

Esto incluye: claves extranjeras -

select * from tblOrder where status_id=:v_outstanding

campos descriptivos -

select * from tblCust where Surname like "O''Brian%"

Las columnas no necesitan ser únicas. De hecho, puede obtener un rendimiento realmente bueno a partir de un índice binario al buscar excepciones.

select * from tblOrder where paidYN=''N''

Todo depende de qué consultas esperas sobre las tablas. Si solicita todas las filas con un cierto valor para la columna X, tendrá que hacer una exploración completa de la tabla si no se puede usar un índice.

Los índices serán útiles si:

La columna o columnas tienen un alto grado de singularidad
Con frecuencia necesita buscar un cierto valor o rango de valores para la columna.

No serán útiles si:

Está seleccionando un gran% (> 10-20%) de las filas en la tabla
El uso de espacio adicional es un problema
Desea maximizar el rendimiento de inserción. Cada índice en una tabla reduce el rendimiento de inserción y actualización porque deben actualizarse cada vez que los datos cambian.

Las columnas de clave principal suelen ser geniales para la indexación porque son únicas y se utilizan a menudo para buscar filas.

Tu clave principal siempre debe ser un índice. (Me sorprendería si no fuera indexado automáticamente por MS SQL, de hecho.) También debe indexar las columnas que SELECT u ORDER con frecuencia; su objetivo es tanto la búsqueda rápida de un solo valor como la clasificación más rápida.

El único peligro real al indexar too columnas es ralentizar los cambios en las filas en tablas grandes, ya que todos los índices también necesitan actualización. Si realmente no está seguro de qué indexar, simplemente cronometra sus consultas más lentas, observe qué columnas se utilizan con más frecuencia e indexelas. Entonces vea cuánto más rápido son.

Una columna GUID no es el mejor candidato para la indexación. Los índices se adaptan mejor a las columnas con un tipo de datos que puede recibir un orden significativo, es decir, ordenado (entero, fecha, etc.).

No importa si los datos en una columna generalmente están aumentando. Si crea un índice en la columna, el índice creará su propia estructura de datos que simplemente hará referencia a los elementos reales en su tabla sin preocuparse por el orden almacenado (un índice no agrupado). Entonces, por ejemplo, se puede realizar una búsqueda binaria sobre su estructura de datos de índice para proporcionar una recuperación rápida.

También es posible crear un "índice agrupado" que reordene físicamente sus datos. Sin embargo, solo puede tener uno de estos por tabla, mientras que puede tener múltiples índices no agrupados.