2010-05-21 8 views
9

Tenemos una aplicación basada en SQL Server de tamaño medio que no tiene índices definidos. Ni siquiera en las columnas de identidad. Le sugerí a nuestro consultor de aplicaciones moderadamente costoso que tal vez podríamos obtener un mejor rendimiento (especialmente a medida que crece nuestra base de datos) creando algunos índices en los campos apropiados, y dijo:¿Es una mala idea agregar índices a un servidor SQL?

"Los índices tendrán un impacto significativo en otras áreas de la aplicación y los clientes no debería crearlos bajo ninguna circunstancia ".

¿Alguien ha oído hablar de algo como esto? ¿Hay alguna vez circunstancias donde uno debería no crear ningún índice? No veo nada especial en esta aplicación: tiene columnas de identidad, muchas columnas de cadenas, muchas tablas relacionales, pero nada especial o extraño que pueda ver.

Gracias!

[EDIT: las columnas de identidad no están utilizando "especificación de la identidad", que parecen estar establecido por el programa, mirando a la base de datos con el estudio de la gerencia, no puedo encontrar NO índices ...]

SEGUIMIENTO: en una conferencia pregunté al CEO (y al arquitecto jefe) de la compañía que producía este producto sobre esto, su respuesta fue que pensaban para implementaciones pequeñas a medianas, la sobrecarga asociada con el mantenimiento de índices tendría un efecto negativo para el usuario en general. experiencia (la aplicación realiza muchas escrituras) de lo que compensarían los beneficios de los índices, pero para bases de datos grandes, crean índices. El técnico de soporte técnico fue demasiado entusiasta y muy inútil con su respuesta. Misterio resuelto.

Respuesta

3

Contrátame y crearé los índices por ti. ¡La experiencia de 14 años de Sybase/SQL Server me dice que cree esos! ¡Maldito! índices A menos que su mesa tenga menos de 500 registros cada uno.

Mi idea es que un nodo de índice hash tiene un tamaño más o menos a 1000.

La otra cosa que hay que tener en cuenta es si el consultor se ha normalizado las tablas. Quizás, la tabla tiene 500 campos/columnas, que contienen más de una entidad conceptual o una docena completa de entidades conceptuales. Y esa podría ser la razón por la que está nervioso acerca de la creación de índices, porque si hay 12 entidades conceptuales en la tabla, habría al menos 12 conjuntos de índices, en cuyo caso, él es absolutamente cierto, bajo ninguna circunstancia ... bla, bla.

Sin embargo, si de hecho tiene 500 columnas o entidades conceptuales detectables múltiples por tabla, es un ingeniero de diseño de datos muy pésimo. En todos mis años trabajando con ingenieros de datos más experimentados, nuestras tablas rara vez superan las 20 columnas. 5 en el lado bajo, 10 en promedio. A veces, por cuestiones de rendimiento, sí permitimos mezclar dos entidades en una tabla u horizontalizar las repeticiones de filas en columnas de una tabla.

Cuando mira el diseño de la mesa puede con un ojo no entrenado ver los registros de Producto, Proyecto, Plano de planta, FloorPlan, Equipo, etc., todo en una larga fila. No puedes mezclar todas estas entidades juntas en una sola tabla.

Esa es la única razón por la que sé por qué podría aconsejarle que no tenga índices.Si él está haciendo eso, debe saber que está representando fraudulentamente sus habilidades de diseño de datos para su empresa y debe eliminarlo inmediatamente de sus gastos contractuales semanales.

OK, después de leer la publicación de larry - Estoy de acuerdo con él también.

+0

Hay algunas tablas con muchas columnas, pero no parecen contener múltiples entidades conceptuales. Las tablas más grandes (en columnas) tienen muchos datos de atributos que parecen estar en un grupo razonable en esa tabla. – Aerik

+0

He visto lo que pensaba que era una buena mesa con 30 columnas. Pero sí, las tablas siguen una distribución de Poisson centrada en aproximadamente 5. – Joshua

0

No tener índices en las columnas de identificación suena realmente inusual y encontraría cualquier justificación para no incluirlos para que huelan muy a pescado.

Debe tener en cuenta que si realiza un gran volumen de confirmaciones en la base de datos, agregar más índices afectará la velocidad de inserción, pero ¿no hay índice en la identificación? Guau.

Sería bueno obtener una mejor justificación de cómo exactamente la adición de índices adicionales podría causar problemas.

3

¿Tiene espacio libre en el disco? He visto casos en los que los índices pesaban más que la tabla.

Sin embargo, ¡no existen índices en absoluto! No puede haber un caso para eso, excepto cuando todas las operaciones de lectura necesitan toda la tabla.

+0

Tenemos un montón de espacio en disco. Y nuestro caso es bastante típico: una gran tabla, y una operación de lectura generalmente busca una fila específica, o hacer una SELECCIÓN SUPERIOR ... ORDEN POR consulta. Entonces no está leyendo toda la mesa. – Aerik

+0

En realidad lo es - sin índice. Sin ningún índice, solo PUEDE leer toda la tabla para cualquier cosa. – TomTom

+1

SELECCIONAR ARRIBA ... ORDER BY se beneficia enormemente de un índice en la columna ORDER BY. – Joshua

2

Las columnas con restricciones de clave tendrán un índice implícito en ellas de todos modos. Entonces, si siempre está seleccionando por la clave principal, entonces no tiene sentido agregar más índices. Si está seleccionando por otros criterios, entonces tiene sentido agregar índices en esas columnas que está consultando.

También depende de qué tan pesados ​​sean sus datos. Si está insertando con más frecuencia de lo que está consultando, entonces la sobrecarga de mantener los índices actualizados puede hacer que sus insertos sean más lentos.

Pero decir que "no debería crear [índices] bajo ninguna circunstancia" es demasiado.

Lo que recomendaría es que ejecute la herramienta SQL Server Profiler con algunas de sus consultas. Esta herramienta recomendará qué índices agregar que tendrán el mayor efecto en el rendimiento.

+0

La aplicación está definitivamente sesgada hacia lecturas que escrituras - parece hacer muchísimo SELECCIONES individuales en lugar de utilizar combinaciones – Aerik

+0

He agregado un poco acerca de la herramienta SQL Server Profiler. Mucho más barato que los "consultores" caros que hablan por el culo, y en realidad son bastante efectivos, también;) –

+0

Gracias por la sugerencia de la herramienta de creación de perfiles: solo he hecho la optimización "a mano" antes. Creo que nuestro verdadero problema será si estamos dispuestos a ir en contra de la recomendación del consultor. El verdadero zinger aquí es que él es de la compañía que escribió la aplicación. – Aerik

0

cuantos más índices tenga, más lentos serán los insertos y modificaciones de datos.Asegúrese de agregar índices cuando sea apropiado y escribir consultas que puedan aprovechar esos índices, también si el nivel de selectividad de su índice es bajo, no se usará efectivamente

1

En la mayoría de las aplicaciones comunes y corrientes , el impacto de los índices en el desempeño de inserción es un poco no problemático. Por lo general, es mejor que cree el índice y si el rendimiento de inserción disminuye drásticamente (lo que probablemente no ocurrirá) puede intentar otra cosa. Obviamente, hay algunas excepciones, donde debe tener más cuidado, como las tablas que se utilizan para el registro, por ejemplo.

Como se mencionó anteriormente, el espacio en disco puede ser un problema.

La creación de índices irrelevantes (por ejemplo, duplicados) también desperdiciará microsegundos y ocasionalmente dará como resultado un plan de ejecución de consultas incorrecto.

El otro problema que he visto es con aplicaciones de código extrañamente de terceros que generan partes de la base de datos en tiempo de ejecución, y pueden eliminar o ahogarse en índices que desconocen.

En la gran mayoría de los casos, un índice cuidadosamente elegido solo será un beneficio.

3

Existe una sobreindexación, especialmente en INSERTAR y ACTUALIZAR aplicaciones pesadas con tablas muy grandes. Entonces, la respuesta a la pregunta en su título es sí, a veces puede ser una mala idea agregar índices.

Esa es una pregunta bastante diferente a la que hace en el cuerpo de su pregunta, que es "¿Es normal tener NO índices en una base de datos de SQL Server". La respuesta es que, a menos que use la base de datos como un sistema de "solo escritura", en el que se agregan datos pero solo se los lee después de extraerlos a granel y transformarlos en otro almacén de datos, es sumamente raro no tener algunos índices en el base de datos.

La declaración de su asesor es lo suficientemente extraña como para hacerme creer que puede haber dejado alguna información importante fuera de su descripción. Si no, diría que está loco.

+0

De hecho, sospecho que está encubriendo un descuido tan flagrante, que su compañía preferiría darnos un mal consejo antes que hacernos saber que se perdieron algo como índices de bases de datos en su diseño. – Aerik

+0

O eso, o él es un completo idiota. He estado en muchos proyectos, también he visto eso, incluido un especialista en base de datos de barracones total que hace campos de texto TEXT porque la longitud no era parte del modelo de objetos (ergo: no indexable, incluso cosas como el número de producto). A la gente le gusta esa zona, y a veces lo son como consultores. Por desgracia. – TomTom

+0

Si tuviera que prescindir de longitudes, usaría postgresql en el que varchar (2000000000) es válido e indexable y no cuesta más que varchar (100) si resulta que varchar (100) era todo lo que necesitaba. – Joshua

Cuestiones relacionadas