Tengo un fondo de Oracle, y el uso de "Tablas organizadas indexadas" (IOT) para cada tabla suena irracional en Oracle y nunca lo he visto. En SQL Server, cada base de datos en la que trabajé tiene un índice agrupado en cada tabla, que es lo mismo que IOT (conceptualmente).Índices agrupados SQL Server
¿Por qué es eso? ¿Hay alguna razón para usar el índice agrupado en todas partes? Me parece que solo serían buenos para un puñado de casos.
Gracias
Sin un índice agrupado, su tabla está organizada como un montón. Esto significa que cada fila que se inserta se agrega en la página de datos al final de la tabla. Además, a medida que las filas se actualizan, se mueven a la página de datos al final de la tabla si los datos actualizados son más grandes que antes.
Cuando es bueno no tener un índice agrupado
Si tiene una tabla que necesita de las más rápidas posibles inserciones, pero puede sacrificar al día, y la velocidad de lectura, entonces no tener un índice agrupado puede trabajar para tú. Un ejemplo sería si tuviera una tabla que se estaba utilizando como cola, por ejemplo, muchas inserciones que luego se leen y se mueven a una tabla diferente.
índices agrupados
Los índices agrupados organizan los datos de la tabla sobre la base de las columnas en el índice agrupado. Si se agrupa en algo incorrecto, por ejemplo, un identificador único, esto puede ralentizar las cosas (ver a continuación).
Siempre que su índice agrupado esté en el valor que se usa con más frecuencia para la búsqueda, y es único, y al aumentar, obtiene increíbles beneficios de rendimiento del índice agrupado.Por ejemplo, si tiene una tabla llamada USUARIOS en la que normalmente busca datos de usuario basados en USER_ID, la agrupación en USER_ID aceleraría el rendimiento de todas esas búsquedas. Esto simplemente reduce la cantidad de páginas de datos que deben leerse para obtener sus datos.
Si tiene demasiadas teclas en su índice agrupado esto puede ralentizar las cosas también.
Reglas generales de los índices agrupados:
No Cluster en las columnas VARCHAR.
La agrupación de columnas IDENTITY INT es lo mejor.
Clúster en lo que busca habitualmente.
La agrupación de UniqueIdentifiers
Con uniqueidentifiers en un índice, que son extremadamente ineficiente porque no hay un orden natural. Con base en la estructura del árbol B del índice, usted termina con índices extremadamente fragmentados al usar uniqueidentifiers. Después de reconstruir o reorganizar, todavía están extremadamente fragmentados. Así que terminas con un índice más lento, que termina siendo realmente enorme en la memoria y en el disco debido a la fragmentación. También en las inserciones del identificador único es más probable que termine con una división de página en el índice, lo que ralentiza su inserción. Generalmente, los únicos identificadores son malas noticias para los índices.
Resumen
Mi recomendación es que cada tabla debe tener un índice agrupado en él a menos que haya una buena razón para no hacerlo (es decir, la tabla que funciona como una cola).
Esto confirma mi comprensión de los índices agrupados. Puedo entender tener índices en las tablas de búsqueda con un número finito de filas. Encaja a la perfección. Y, básicamente, un montón de tablas de hechos que sigue creciendo, y que se ordenan naturalmente cuando se insertan. La que me desconcertó todo el tiempo es la que describes por "Clustering on UniqueIdentifiers", heredé una base de datos con una de esas en una tabla de filas de 2B. ¡Nunca tuvo sentido para mí! Además de eso, tenía un trabajo automatizado para reconstruirlo. Gracias, muchas cosas comienzan a tener sentido ahora. – Younes
Estamos utilizando claves principales en bases de datos relacionales y en la relación general se establece a través de estas claves primarias. La mayoría de las personas solía nombrar el primer campo como TableID y convertirlo en clave principal. Cuando une dos o más tablas en su consulta, obtendrá el resultado más rápido si utiliza índices agrupados.
No sé por qué preferiría un montón sobre un índice agrupado la mayor parte del tiempo. Al usar clustering, obtienes un índice de tu elección gratis. La mayoría de las veces esta es la clave principal (¡que probablemente quiera aplicar de todos modos!).
Los montones son principalmente para situaciones especiales.
Un índice agrupado no es exactamente lo mismo que una tabla organizada por índice. Con un IOT, cada campo debe participar en la clave IOT. Un índice agrupado en SQL Server no tiene que ser único, y no tiene que ser la clave principal.
Los índices agrupados son ampliamente utilizados en SQL Server, ya que casi siempre hay un orden natural que hace que una consulta de uso común sea más eficiente. Los IOT en Oracle llevan más equipaje, por lo que no son tan útiles, aunque pueden ser más útiles, por lo general reciben crédito.
Históricamente, las versiones realmente antiguas de SQL Server pre 6.5 o 7.0 IIRC no admitían el bloqueo a nivel de fila y solo podían bloquearse a nivel de tabla o página. A menudo, se usaría un índice agrupado para garantizar que las escrituras estuvieran dispersas en el almacenamiento físico de la tabla para minimizar la contención en los bloqueos de página. Sin embargo, SQL Server 6 fue compatible hace algunos años, por lo que las aplicaciones con este problema estarán restringidas a los sistemas heredados raros.
Por lo general, no me molestan los índices agrupados en la tabla de dimensiones (tablas pequeñas). Sin embargo, en las tablas de hecho, no estoy seguro de que sea una buena idea, ralentiza la carga y el escaneo completo. Y en casi todos los casos, el orden natural se basa en el tiempo, generalmente el orden en que se cargaron los datos. – Younes
@Younes: los índices agrupados no son muy útiles en una tabla de hechos, ya que la mayoría de las consultas implican un examen de tabla. Tal vez con una versión que no admita particiones (por ejemplo, la edición 2012 de B.I.), quizás desee utilizar un índice agrupado en la columna de fecha o período para minimizar las operaciones de E/S en carga o archivo. Las consultas con rangos de fechas también pueden usar el índice agrupado para reducir las E/S al usar operaciones de escaneo de rango. – ConcernedOfTunbridgeWells
Aquí es una cuestión relacionada con el [DBA-SE] (http://dba.stackexchange.com/) con algo de información y un par de enlaces donde se puede leer en. [Rendimiento de la No índices agrupados en montones vs índices agrupados] (http://dba.stackexchange.com/questions/9829/performance-of-non-clustered-indexes-on-heaps-vs-clustered-indexes) –
Probablemente una pregunta mejor respondida por alguien familiarizado con Oracle y SQL Server. [dba.se] podría ser una mejor ubicación para esto. –
Además, sugiero que mueva esta pregunta a dba.se. Se han recibido dos comentarios y una respuesta (pura coincidencia) de clientes habituales de DBA.SE sin que ninguno de los otros carteles haya detectado realmente que los índices agrupados y las IOT tienen diferencias significativas. – ConcernedOfTunbridgeWells