¿La longitud del campo de la base de datos (máxima) afecta el rendimiento?

En mi empresa, tenemos una base de datos heredada con varias tablas y, por lo tanto, muchos, muchos campos.¿La longitud del campo de la base de datos (máxima) afecta el rendimiento?

Muchos de los campos parecen tener límites grandes (por ejemplo, NVARCHAR(MAX)) que nunca se alcanzan.

¿Hacer arbitrariamente los campos su ancho máximo o 2 a 3 veces más grande de lo que normalmente se introduce afecta negativamente el rendimiento?

¿Cómo se debe equilibrar el rendimiento con las longitudes de campo? ¿Hay un equilibrio?

Fuente

2011-03-18 dotnetN00b

No es mucho, pero no puede indexar una columna de tipo 'VARCHAR (MAX) '- eso podría ser un gran inconveniente ... (cualquier índice puede tener un máximo de 900 bytes, una columna (MAX) * podría * ser de hasta 2 GB, por lo que no puede formar parte de ningún índice) –

Relacionado/Duplicado http://stackoverflow.com/questions/4378795/sql-performance-is-there-any-performance-hit-using-nvarcharmax-instead-of-nvar –

posible ¿duplicado de [varchar (max) en todas partes?] (http://stackoverflow.com/questions/2091284/varcharmax-everywhere) – Justin

Hay dos partes en esta pregunta:

¿El uso NVARCHAR sobre el rendimiento herida VARCHAR? Sí, almacenar datos en campos Unicode duplica los requisitos de almacenamiento. Los datos almacenados en esos campos tienen un tamaño 2 veces mayor (hasta que salió SQL Server 2008 R2, que incluye unicode compression. Los escaneos de la tabla demorarán el doble y se almacenará la mitad de la información en la memoria del caché del búfer .

¿El uso de MAX funciona mal? No directamente, pero si usa VARCHAR (MAX), NVARCHAR (MAX), y ese tipo de campos, y si necesita indexar la tabla, no podrá reconstruya esos índices en línea en SQL Server 2005/2008/R2. (Denali aporta algunas mejoras en las tablas con campos MÁX para reconstruir algunos índices en línea.)

Fuente

2011-03-22 11:43:09

No puede indexar 'VARCHAR (MAX)' y campos relacionados. – Justin

Lo siento, debería ser más específico: si necesita indexar esas TABLAS, no podrá volver a generar esos índices en línea. Una tabla con esos campos no puede reindexarse en línea en SQL Server 2005/2008/2008R2. –

Sí, el optimizador de consultas puede adivinar cuántas filas caben en una página, si tiene muchos campos varchar que son más grandes que lo necesario, SQL Server puede adivinar internamente el número de filas incorrecto.

Fuente

2011-03-18 14:11:39

el optimizador de consultas usa 'qué tan ancha es la fila' para estimar 'cuántas filas pueden caber por página'. –

-2

Para el rendimiento, la respuesta es NO para la mayoría de los casos. Creo que puede analizar el rendimiento desde el nivel de la aplicación: recopilar los datos, obtener los requisitos y luego hacer algunos análisis. El cuello de botella puede ser causado por código de aplicación, SQL o diseño de esquema.

Fuente

2011-03-19 13:30:29 user205993

¿La longitud del campo de la base de datos (máxima) afecta el rendimiento?

Respuesta

Cuestiones relacionadas