2010-07-19 24 views
7

Para usted gurus de diseño/rendimiento de bases de datos.Sql Server int vs comparación nvarchar en el rendimiento?

Estoy diseñando una tabla, tengo la opción de usar int o nvarchar (128) para una columna, supongo que el espacio no es un problema. Mi pregunta es lo que dará un rendimiento

cuando busco con la columna int

where ID = 12324

o cuando lo busco con la columna nvarchar (la clave es el valor completo, así que no estoy utilizando como operador)

where Key = 'my str'

estoy seguro de conjuntos de datos más pequeños no importa, pero vamos a suponer que estos datos estará en los millones de filas.

Respuesta

17

INT será más rápido - he aquí por qué:

  • SQL Server organiza sus datos e índice en las páginas de 8K
  • si usted tiene una página de índice con la tecla INT en ella, se obtiene aproximadamente 2'000 INT entradas
  • si tiene nvarchar (128) y utiliza un promedio de 20 caracteres, que es de 40 bytes por entrada, o cerca de 200 entradas por página

Así que para la misma cantidad de entradas de índice, el nvarchar (128) ca se usaría diez veces más páginas de índice.

Cargando y buscando esas páginas de índice incurrirá significativamente más operaciones de E/S.

Para hacer las cosas cortas: si puedes, siempre usa INT.

5

El principal problema con el rendimiento con esto es el tamaño del campo: un int tiene 4 bytes, mientras que un nvarchar(128) tendrá 254 bytes.

Todo esto necesita ser administrado por el servidor SQL, por lo que la gestión de un int será mucho más rápido que un nvarchar(128).

+1

+1 buen punto. Además, hay un poco menos de trabajo para que una CPU procese un int en lugar de una cadena. Con millones de filas, esto podría generar una diferencia no despreciable. Me interesaría ver algunas pruebas de rendimiento real en esto. –

8

Espacio es siempre un problema en las bases de datos. Las teclas más amplias significan menos entradas por página, más páginas escaneadas para agregar y sumar valores, significa más IO, menos rendimiento. Para los índices agrupados, este problema se multiplica por cada índice no agrupado, ya que tienen que reproducir la clave de búsqueda (clave agrupada) en sus hojas. Por lo tanto, una clave del tipo nvarchar(128) será casi siempre será peor que una INT.

Por otro lado, no use una tecla INT si no es apropiado. Utilice siempre la clave adecuada, teniendo en cuenta sus consultas. Si siempre consulta por un valor de columna nvarchar (128), entonces es posiblemente un buen candidato clave en clúster. Si va a agregado con la tecla nvarchar (128), entonces es probable un buen candidato clave en clúster.

+2

+1: teclas naturales> artificiales, pero hay muy pocas teclas naturales IME. –

0

Usaría int para el rendimiento (si esto va a tener uniones especialmente) y pondré un índice único sobre la clave natural potencial para la integridad de datos.

Cuestiones relacionadas