Supongamos que tengo una tabla con un gran número de filas y una de las columnas que quiero indexar puede tener uno de los 20 valores. Si tuviera que poner un índice en la columna, ¿sería grande?¿Los índices se chupan en SQL?
Si es así, ¿por qué? Si tuviera que particionar los datos en los datos en 20 tablas, una para cada valor de la columna, el tamaño del índice sería trivial, pero el efecto de indexación sería el mismo.
Los índices son puramente de rendimiento. Si un índice no aumenta el rendimiento de las consultas que le interesan, entonces apesta.
En cuanto al uso del disco, debe sopesar sus inquietudes. Diferentes proveedores de SQL crean índices de manera diferente, pero como cliente, generalmente confías en que hacen lo mejor que se puede hacer. En el caso que está describiendo, un índice agrupado puede ser óptimo para el tamaño y el rendimiento.
"Si un índice no aumenta el rendimiento de las consultas que le interesan, entonces apesta". Me gustaría diferir. Estoy de acuerdo, si el índice no sirve para nada, es solo una carga adicional. Pero el propósito puede ser mucho más amplio que la consulta o las consultas que estás examinando actualmente. – HLGEM
Tienes razón ... exageré un poco. Después de publicar, pensé, podría estar diseñado para escenarios de datos futuros. – harpo
Digamos que tengo una tabla con un gran número de filas y una columna que quiero indexar puede tener uno de los 20 valores. Si tuviera que poner un índice en la columna, ¿sería grande?
El tamaño del índice será proporcional al número de sus filas y la longitud de los valores indexados.
El índice mantiene no sólo el valor indexado, sino también algún tipo de un puntero a la fila (ROWID en Oracle, LCID en PostgreSQL, clave principal en InnoDB etc).
Si tiene 10,000 filas y un valor distinto de 1, todavía tendrá 10,000 registros en su índice.
Si es así, ¿por qué? Si tuviera que dividir los datos en los datos en 20 mesas, una para cada valor de la columna, el tamaño del índice sería trivial, pero el efecto de indexación sería el mismo
En este caso, vendría con 20 índices tienen el mismo tamaño en total que el original.
Esta técnica a veces se usa de hecho en los llamados índices particionados. Tiene sus ventajas y desventajas.
En Oracle, la opción COMPRESS en la creación de índices puede reducir la necesidad de tener múltiples copias del mismo valor indexado representado en el índice. Sin embargo, todavía necesitas todos los rowids. –
Mi punto es que si participo en 20 tablas, entonces no necesitaría ningún índice en la columna, ya que sé que cada fila de la columna tiene el mismo valor. –
Si se divide en 20 tablas, ni siquiera necesita la columna – Quassnoi
Sería lo suficientemente grande como para mantener esos valores para todas las filas, en un orden ordenado.
Supongamos que tiene 20 cadenas diferentes de 4 caracteres y 1 millón de filas, que serían al menos 4 millones de bytes (u 8 si es de Unicode de 16 bits) para mantener esos valores.
Bueno, no necesariamente. Si todas las filas de una página tuvieran el mismo valor de columna, por ejemplo, un motor de indexación inteligente podría usar menos espacio registrando ese hecho en su lugar. En mi humilde opinión, podría equivocarme fácilmente ... –
La respuesta corta: Haz índices chupan: Sí y No
La respuesta larga: Ellos no chupan si se utiliza correctamente. Tal vez debería comenzar a leer sobre cómo funcionan los índices, por qué pueden funcionar y por qué a veces no funcionan.
buenos puntos de partida: http://www.sqlservercentral.com/articles/Indexing/
No es el indexa que chupar. Está poniendo índices en las columnas incorrectas que apestarán.
En serio, ¿por qué necesitaría una tabla con una sola columna? ¿Cuál sería el significado de esa información? ¿Qué propósito tendría?
Y 20 tablas? Le sugiero que lea primero en database design o que nos explique el contexto de su pregunta.
He visto una base de datos con una tabla separada para cada atributo de las entidades reales. Por qué: quieren el historial de versiones y el viaje en el tiempo para cada atributo. Imagina esa base de datos con 300 tablas, donde la mayoría de los campos son del tipo "DateTime" ... – thijs
@thijs pero aún necesitarías dos columnas, una como la clave y otra como el atributo –
. Lo expresé mal. Hay una columna que quiero indexar, no una columna en total. Editaré mi pregunta con más detalles de la estructura de la tabla. –
Lo siento, no estoy muy seguro de lo que quiere decir con "grande".
Si está agrupado el índice, todos los datos para cada registro estarán en la misma página de la hoja, creando así el índice más eficiente disponible a su mesa, siempre y cuando usted escribe sus consultas en forma adecuada.
Si su índice no está agrupado, solo los datos relacionados con el índice estarán en las páginas de su hoja. Luego, dependiendo de cosas tales como cuántos otros índices tiene, junto con detalles como su factor de relleno, su índice puede ser o no eficiente. En general, si no tienes muchos índices en tu mesa, deberías estar a salvo.
La eficiencia de su índice también estará determinada por el tipo de datos de los 20 valores de los que habla al ingresar a la columna. Si esos son valores predefinidos, entonces sus detalles probablemente deberían estar en una tabla de búsqueda con un tipo de datos de clave primaria simple (como Int/Number). A continuación, agregue esa columna a su tabla como una clave externa con un índice en la columna.
En última instancia, podría tener un índice perfecto en una columna. Pero su mejor uso estará determinado en gran parte por las consultas que escriba. Entonces, si sus consultas hacen uso de los índices, está satisfecho.
La tabla tiene 600 millones de filas. Hay alrededor de 5 columnas, todas menos una se usan para seleccionar el filtro y una que es la columna de datos. Pero, por el bien de esta pregunta podríamos decir que hay 3 columnas. Col1, Col2, Col3. Digamos que Col1 es el PK y col2 tiene 20 valores posibles y col3 es la columna de datos –
. Me parece que hay algo mal si el índice en Col2 es masivo, ya que puedo hacer rodar mi propio índice dividiéndolo en 20 tablas, 1 por valor de Col2. –
En 600M filas, espero que estés hablando de una tabla OLAP, no una tabla OLTP. ¡Hay muchas filas para administrar! Ahora está entrando en la teoría de arquitectura de DB de almacén serio que debería tener en cuenta muchos otros factores de su base de datos. Me encantaría saber tu decisión final. – Boydski
Los índices b-tree estándar son los más adecuados para índices bastante selectivos, que este ejemplo no sería. Usted no dice qué DBMS está usando; Oracle tiene otro tipo de índice llamado índice de mapa de bits que es más adecuado para índices de baja selectividad en entornos OLAP (ya que estos índices son costosos de mantener, lo que los hace inadecuados para entornos OLTP).
El optimizador decidirá bases en estadísticas si cree que el índice ayudará a obtener los datos en el tiempo más rápido; si no lo hace, el optometrista no lo usará.
El particionamiento es otra estrategia. En Oracle puede definir una tabla como particionada en algún conjunto de columnas, y para el optimizador puede realizar automáticamente la "eliminación de partición" como sugiere.
FYI: Partición de tablas (datos extendidos sobre archivos) en función del contenido de las columnas también es posible en MSSQL 2005 y hasta – thijs
Los índices (o índices) no son una mierda. Muchas personas muy inteligentes han pasado una cantidad de tiempo realmente notable durante las últimas décadas, asegurando que esto sea así.
Su esquema, sin embargo, que carece de la misma cantidad de experiencia y esfuerzo, puede ser muy malo.
El particionamiento, en el caso descrito es equivalente a aplicar un índice agrupado. Si la tabla está ordenada de otra manera (o está en orden arbitrario), entonces el índice necesariamente tiene que ocupar mucho más espacio. Dependiendo de la plataforma, un índice no agrupado puede reducirse en tamaño a medida que aumenta la ordenación de las filas con respecto al valor indexado.
YMMV.
¡Bueno! Sospeché que esta partición era como usar un índice agrupado. Esto me lleva a la pregunta: ¿hay algún valor para particionar la tabla sobre el uso de un índice agrupado? Creo que el rendimiento alcanzado sería mínimo en las inserciones si solo necesito agregar un poco de código para elegir la tabla correccional –
correcta para insertar. ¿Habría un mayor rendimiento si utilicé un índice agrupado? ¿Los datos tienen que cambiar mucho en cada inserción donde hay un índice agrupado, o es más inteligente que eso? –
Una tabla con un índice agrupado está (por definición) ordenada en las columnas indexadas. Entonces, insertar en todos los valores probablemente va a costar. Sin embargo, en realidad podría ser peor con una tabla dividida, tendría que chuparla y ver. ¡No olvide probar un índice no agrupado en la comparación, tampoco! –
Ningún índice no es malo, pero debes prestar atención a cómo los usas o pueden ser contraproducentes en el rendimiento de tus consultas.
Primero: Esquema/diseño
¿Por qué se crea una tabla con una sola columna? Eso probablemente lleve la normalización un paso más lejos. diseño de base de datos es una de las cosas más importantes a tener en cuenta en la optimización del rendimiento
Segundo: Índices
En pocas palabras los índices ayudarán a la base de datos para realizar una búsqueda binaria de su registro. Sin un índice en una columna (o conjunto de columnas), la base de datos a menudo recurrirá a un escaneo de tabla. Un escaneo de tabla es muy costoso porque implica enumerar todos y cada uno de los registros.
Realmente no importa TANTO para escaneos de índice cuántos registros hay en la tabla de la base de datos. Debido a la búsqueda de árbol binario (equilibrado), doblar la cantidad de registros solo dará como resultado un paso de búsqueda adicional.
Determine la clave principal de su tabla, SQL colocará automáticamente un índice agrupado en esa (s) columna (s). Los índices agrupados funcionan muy bien. Además, puede colocar índices no agrupados en columnas que se utilizan con frecuencia en las instrucciones SELECT, JOIN, WHERE, GROUP BY y ORDER BY. Recuerde que los índices tienen cierta superposición, intente nunca incluir su índice agrupado en un índice no agrupado.
También es interesante el factor de relleno en los índices. ¿Desea optimizar su tabla para lecturas (alto factor de relleno - menos almacenamiento, menos E/S) o para escrituras (bajo factor de relleno más almacenamiento, menos reconstrucción de sus páginas de base de datos).
Tercero: La partición
Una de las razones para utilizar la partición es optimizar el acceso a datos. Digamos que tiene 1 millón de registros de los cuales 500,000 registros ya no son relevantes, sino que se almacenan para fines de archivo. En este caso, puede decidir dividir la tabla y almacenar los 500,000 registros antiguos en almacenamiento lento y los otros 500,000 registros en almacenamiento rápido.
Para medir es saber
La mejor manera de conseguir la penetración en lo que sucede es medir lo que sucede a su CPU y el io. Microsoft SQL Server tiene algunas herramientas como Profiler y planes de ejecución en Management Studio que le indicarán la duración de su consulta, el número de lecturas/escrituras y el uso de la CPU. Además, el plan de ejecución le indicará qué índice o si se están utilizando los índices. Para su sorpresa, es posible que vea un escaneo de tabla aunque no lo esperaba.
Heh, no quise decir que la tabla tiene solo una columna. Quiero decir que tiene una columna en particular que quiero indexar. He editado la pregunta para aclarar esto. –
Excelente respuesta. Muy detallado. –
El efecto de indexación sería el mismo, pero ¿qué ocurre cuando se quiere un segundo índice? –