Índice en un Varchar?

Question

Estamos sufriendo algunos problemas graves de bloqueo de tablas en la producción. Me di cuenta de que creé un procedimiento almacenado que obtiene una lista de pedidos por número de orden. El número de pedido es un VARCHAR (150). No hay ningún índice de ningún tipo en esta columna.

Por el momento, hay MUCHOS valores NULOS en esta columna. Sin embargo, con el tiempo (esta tabla se puso en funcionamiento recientemente), la tabla crecerá significativamente. No se agregarán más valores NULL en este momento.

Mi pregunta es doble. En primer lugar, un índice sería beneficioso aquí. El proceso es muy utilizado. Y si es así, ¿debería estar agrupado o no? Los datos son cosas como CP123456, DR126512.

La segunda pregunta, que probablemente influya en la primera pregunta es: ¿sería beneficioso cambiar la columna a CHAR (10), ya que 'parece' que el número de orden siempre es del mismo tamaño. ¿Hay algún beneficio de velocidad al poner un índice en un CHAR de longitud fija, a diferencia de un VARCHAR (150)?

(El tamaño diferente se debe a requisitos desconocidos cuando se creó la columna).

SQL Server 2008.

Answer 1

1. Sí, por supuesto! Adelante, agrega un índice. La agrupación del índice probablemente sea innecesaria aquí, y no será posible de todos modos si ya tiene otro índice agrupado (como la clave principal) en la tabla.

2. Cambiar la columna a CHAR(10) puede tener algunos beneficios en términos de tamaño de almacenamiento, pero es poco probable que haga una gran diferencia en el rendimiento del índice. Me lo saltaría por ahora.

Answer 2

No tengo referencias para citar sobre esto, solo la experiencia/evidencia anecdótica.

En primer lugar, las consultas pueden casi siempre ser mejorado mediante el uso de índices. El beneficio exacto depende de la consulta.
- Si una consulta requiere sólo registros específicos/una pequeña porción de la tabla, un índice ayudará
- Si una consulta requiere que toda la mesa, pero podría beneficiarse de datos ordenados, un índice ayudará

Los índices agrupados generalmente proporcionan beneficios de rendimiento sobre los índices no agrupados. En un sentido muy simplificado, usar un índice no agrupado es como usar dos tablas y unirlas (primero se usa el índice de búsqueda fácil, que luego se une a los datos en sí, a menos que el índice contenga todos los campos de datos que necesita).

Una consideración aquí, sin embargo, es el orden en que se agregan los datos a su tabla. Si su índice agrupado significa que los datos a menudo se insertan o eliminan en el medio de la tabla, obtendrá fragmentación y otros artefactos. En mi experiencia, sin embargo, la conciencia y la consideración de esto solo son necesarias en situaciones extremas.

En resumen, DEFINITIVAMENTE indexar sus datos. Y el índice agrupado normalmente está en mejor posición para atender sus consultas de peor rendimiento.

En cuanto a la diferencia entre VARCHAR y CHAR? En el pasado, era importante mantener campos de longitud variable al final de sus datos, para hacer que los campos de longitud fija fueran más fáciles de identificar. Esto significaba que tener un campo VARCHAR como su primer campo, y usarlo como un identificador único, era bastante pobre.

Hoy en día, la diferencia de rendimiento es marginal. Personalmente, aún conservaría los identificadores únicos como longitud fija. Los datos de longitud variable normalmente no tendrán costos de rendimiento notables, pero cuando hace comparaciones para los predicados de unión, etc., es mucho más ordenado tener campos de longitud fija si es posible.