2010-08-31 15 views
8

Estoy actualizando una base de datos Jet a SQL Server Express 2008 R2 y antes de hacerlo, estoy reevaluando el esquema (fue diseñado en 1997-98, y el tipo que diseñado (es decir, yo) era algo así como un idiota!).Indexando campos individuales de claves compuestas de SQL Server

Mi pregunta es sobre tablas de combinación N: N con una clave compuesta de dos columnas. En Jet, las uniones en la primera columna de una clave compuesta de dos columnas usarán el índice compuesto, pero las uniones en la segunda columna no, por lo general, en las bases de datos Jet con grandes N: N unen tablas con un número razonablemente grande de registros Además del índice compuesto, agrego un segundo índice no único en la segunda columna.

¿Es esta una buena idea en SQL Server?

(tal vez no es una buena idea en Jet?)

Respuesta

14

se aplican las mismas reglas en SQL Server. Si tiene un índice en (Columna A, Columna B), una consulta solo en Columna A o Columna A y Columna B juntas puede usar el índice, pero una consulta solo en Columna B no puede. Si hay una necesidad de unirse solo a ColumnB, entonces definitivamente debe crear el índice.

+0

¿Algún inconveniente, aparte de los problemas obvios de mantenimiento de índice? –

+2

Consideraciones de espacio para almacenar el índice. Gastos generales adicionales en las operaciones Insert/Update/Delete. También considere la cardinalidad de ColumnB. Si es baja cardinalidad (pocos valores únicos), el índice puede no ser de mucha ayuda. –

+0

En general, mi ColumnB tiene una cardinalidad menor que ColumnA. ¿Sería más eficiente invertirlos y agregar el índice no duplicado en la columna con mayor cardinalidad? –

5

Si usted tiene un índice compuesto sobre columnas (A,B) ninguna Búsqueda, Escaneo gama, tipo u operación agregada se puede utilizar para expresiones que contienen solamente B. Esto es cierto para SQL Server, al igual que para los controladores Jet (Rojo) (y creo que también para Jet Blue). Algunos otros motores pueden usarlo en una operación llamada skip scan.

Así que la respuesta es que necesita índices separados en (B) solo.

+0

Si la tabla se usa principalmente con uniones en ambas columnas, ¿le ayudará SELECCIONAR tanto como lo haría en un SELECCIONAR usando solo la 2da columna de una unión? Mi idea es que el optimizador va a seleccionar primero en el lado que tiene un índice y luego tiene menos que hacer en el otro lado, por lo que con ambas uniones será más eficiente que con la unión solo en el lado no indexado. Como casi nunca utilizo tablas de combinación sin ambas uniones, ¿quizás no sea de mucha ayuda? –

+0

Si la unión está en ambas columnas, es probable que se ignore el índice en '(B)' solo. Pero si busca/une principalmente en 'A' y' B', * algunas veces * en 'B' solamente pero * nunca * en' A' solo, entonces podría considerar cambiar el índice para que esté en '(B, A)' en lugar. –

+0

Como regla general, el orden de las columnas en un índice debe aumentar el orden de selectividad, a menos que sea necesario abordar 'ORDER BY' específico.Colocar columnas de baja selectividad en el lado izquierdo permite que las consultas de agregado y de rango grande sigan usando el índice, pero tenga en cuenta que una columna de baja selectividad también caerá rápidamente en la trampa del punto de inflexión: http://www.sqlskills.com/BLOGS /KIMBERLY/category/The-Tipping-Point.aspx. Tener una columna de baja selectividad (como 'Tipo') en el extremo izquierdo tiene más sentido en los índices agrupados porque los índices agrupados siempre están cubriendo, no tienen un punto de inflexión. –

4

Para obtener más información, solo un consejo, en el servidor SQL que utiliza el estudio de gestión, puede evaluar el rendimiento mediante "Mostrar el plan de ejecución estimado". Se muestra cómo funcionan los índices y la combinación.

También puede usar el DTA (Database Engine Tuning Advisor) para obtener más información y optimización.

Cuestiones relacionadas