¿Cómo afectan las columnas largas el rendimiento y el uso del disco?


26

En nuestro proyecto actual, sucede con demasiada frecuencia, que necesitamos extender las columnas por un par de caracteres. De varchar(20)a varchar(30)y así sucesivamente.

En realidad, ¿cuánto importa realmente? ¿Qué tan bueno es esto optimizado? ¿Cuál es el impacto de solo permitir 100 o 200 o incluso 500 caracteres para los campos de "entrada" normales? Un correo electrónico solo puede tener 320 caracteres, así que está bien, hay un buen límite allí. Pero, ¿qué gano si lo configuro en 200, porque no espero direcciones de correo electrónico más largas que eso?

Por lo general, nuestras tablas no tendrán más de 100.000 filas y hasta 20 o 30 de esas columnas.

Usamos SQL Server 2008 ahora, pero sería interesante saber cómo las diferentes bases de datos manejan estos problemas.

En caso de que el impacto sea muy bajo, como era de esperar, sería útil obtener algunos buenos argumentos (¿respaldados con enlaces?) Para convencer a mi DBA de que esta paranoia de campo largo no es realmente necesaria.

En caso de que sea así, estoy aquí para aprender :-)

Respuestas:


12

La respuesta específica a su pregunta (al menos para Oracle y probablemente otras bases de datos) es que la longitud del campo no importa, solo la longitud de los datos. Sin embargo, esto no debe usarse como un factor determinante con respecto a si establecer el campo a su longitud máxima permitida o no. Aquí hay otros problemas que debe considerar antes de maximizar el tamaño de los campos.

Formateo Cualquier herramienta de cliente que formatee los datos en función del tamaño de los campos requerirá consideraciones especiales de formateo. El SQL * Plus de Oracle, por ejemplo, muestra de forma predeterminada el tamaño máximo de las columnas Varchar2 incluso si los datos tienen solo un carácter. Comparar…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

La longitud del campo de datos incorrectos proporciona un mecanismo adicional para capturar / prevenir datos incorrectos. Una interfaz no debería intentar insertar 3000 caracteres en un campo de 100 caracteres, pero si ese campo se define como 4000 caracteres, simplemente podría hacerlo. El error no se detectará en la etapa de entrada de datos, pero el sistema puede tener problemas más abajo cuando otra aplicación intente procesar los datos y bloqueos. Como ejemplo, si luego decide indexar el campo en Oracle, excedería la longitud máxima de la clave (dependiendo del tamaño del bloque y la concatenación). Ver…

create index i1 on f1(a);

Memoria Si la aplicación cliente asigna memoria usando el tamaño máximo, la aplicación asignaría significativamente más memoria de la necesaria. Tendrían que hacerse consideraciones especiales para evitar esto.

Documentación El tamaño del campo proporciona otro punto de documentación de datos sobre los datos. Podríamos llamar a todas las tablas t1, t2, t3, etc. y a todos los campos f1, f2, f3, etc., pero al especificar nombres significativos entendemos mejor los datos. Por ejemplo, si una tabla de direcciones para una empresa con clientes en los EE. UU. Tiene un campo llamado Estado que tiene dos caracteres, esperamos que la abreviatura de estado de dos caracteres vaya en él. Por otro lado, si el campo tiene cien caracteres, podríamos esperar que el nombre de estado completo vaya en el campo.


Dicho todo esto, parece prudente estar preparado para el cambio. El hecho de que todos los nombres de sus productos en la actualidad tengan 20 caracteres no significa que siempre lo harán. No se exceda y llegue al 1000, pero deje espacio para una expansión plausible.



La documentación es buena y la agregaste aquí y no la he visto en ningún otro lado.
jeteon 01 de

9

Aquí hay un buen punto de partida para ti.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Puede que haya entendido mal su pregunta original. Déjame ver si puedo encontrarte algunos otros enlaces para referencia.

Aquí hay una buena referencia sobre las selecciones de tipos de datos: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Cambiar de varchar (20) a varchar (30) puede parecer algo pequeño, pero debe comprender mejor cómo funcionan las estructuras de la base de datos para estar al tanto de los posibles problemas. Por ejemplo, ir a varchar (30) podría empujarlo más allá del punto de inflexión de sus columnas (en caso de que se usen los 30 bytes) pudiendo almacenarse en una página (menos de 8060 bytes). Esto conducirá a un aumento en el espacio en disco utilizado, una disminución en el rendimiento e incluso una sobrecarga adicional con sus registros de transacciones.

Aquí hay un enlace para estructuras de bases de datos: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Aquí hay uno para divisiones de página y registro de trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

Pensé en compartir otro punto interesante, que encontré en la siguiente Pregunta SO:

/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Respuesta original de: Nick Kavadias

Una razón para NO utilizar los campos max o text es que no puede realizar [reconstrucciones de índice en línea] [1], es decir, RECONSTRUIR CON ONLINE = ON incluso con SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "reconstrucciones de índices en línea"

Consideraría que esto es una gran desventaja al agregar arbitrariamente columnas n / varchar (max), y según el sitio de MS, esta restricción contra la reconstrucción de índices en línea permanece en SQL Server 2008, 2008 R2 y Denali; por lo que no es específico de SQL Server 2005.

Gracias Jeff


6

En algunos casos, la cantidad de espacio que asigna para un campo varchar afectará la cantidad de memoria asignada para los tipos en memoria.

Las presentaciones en SQLWorkshops.com me parecieron estimulantes, esta presentación habla sobre un caso en el que un tipo de orden se está extendiendo a tempdb porque no se está asignando suficiente memoria para los campos char / varchar.

http://webcasts2.sqlworkshops.com/webcasts.asp

Este webcast también se presentó como un artículo en el siguiente sitio web:

http://www.mssqltips.com/tip.asp?tip=1955

Tenga en cuenta en esta presentación que la columna que se está ordenando no es la columna char / varchar, pero la cantidad de espacio asignado para la columna varchar en la memoria hace una diferencia en el rendimiento de la consulta en algunos casos.


4

SET ANSI_PADDING ON?

Terminas con mucho espacio en blanco al final ...


3

Importa solo en relación con el espacio en disco y la longitud de los caracteres. Por supuesto, la búsqueda de tipos de datos de caracteres y los índices de este tipo de datos actuarán más lentamente que los enteros, pero esta es otra discusión.

El tipo de datos Varchar es un tipo de datos "variable", por lo que si configura un límite de varchar (500), esta es la longitud máxima de caracteres para ese campo. La longitud mínima puede estar entre 0 y 500. Por otro lado, el espacio en disco reclamado será diferente para los campos de 10, 30 o 500 caracteres.

A veces hice una prueba para el tipo de datos varchar (800) y para los valores nulos tenía 17 bytes utilizados, y para cada carácter insertado agregaba un byte más. Por ejemplo, una cadena de 400 caracteres tenía 417 bytes utilizados en el disco.


3

No creo que haya ninguna diferencia entre las tablas creadas con columnas de varchar (20) o varchar ((8000), siempre que la longitud máxima real sea <= 20.

Por otro lado, en algunos casos, dar a los usuarios la posibilidad de almacenar cadenas más largas podría alentarlos a hacerlo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.