¿Cuándo usar TINYINT sobre INT?

En general, siempre uso Ints. Sin embargo, sé que, en teoría, esta no es la mejor práctica, ya que debe usar el tipo de datos más pequeño que se garantizará para almacenar los datos.

Por ejemplo, es mejor usarlo tinyintcuando sabe que los únicos datos que almacenará son 1, 0 o nulos (con una posibilidad muy pequeña de expandirlos a 2 o 3 más adelante).

Sin embargo, la única razón que sé para hacer esto es para fines de almacenamiento: usar 1 byte en una fila en lugar de 4 bytes.

¿Cuáles son los impactos del uso tinyint(o smallintincluso bigint) sobre solo int, aparte de ahorrar espacio en su disco duro?

El espacio en disco es barato ... ¡ese no es el punto!

Deje de pensar en términos de espacio de almacenamiento, piense en la agrupación de almacenamiento intermedio y el ancho de banda de almacenamiento . En el extremo, la memoria caché de la CPU y el ancho de banda del bus de memoria . El artículo vinculado es parte de la serie que destaca los problemas con una selección de clave agrupada deficiente (INT vs GUID vs Secuencial GUID) pero destaca la diferencia que pueden hacer los bytes.

El mensaje principal es que el diseño es importante. La diferencia no se mostrará en una base de datos individual en un servidor adecuadamente especificado hasta que llegue al territorio VLDB, pero si puede guardar algunos bytes, ¿por qué no hacerlo?

Me recuerda el entorno descrito en una pregunta anterior . Más de 400 bases de datos, que varían en tamaño desde 50mb-50GB, por instancia de SQL. Eliminar algunos bytes por registro, por tabla, por base de datos en ese entorno podría marcar una diferencia significativa.

Además de las otras respuestas ...

Las filas y las entradas de índice se almacenan en páginas de 8k. Por lo tanto, un millón de filas a 3 bytes por fila no son 3 MB en el disco: afecta el número de filas por página ("densidad de página").

Lo mismo se aplica a nvarchar a varchar, smalldatetime a datetime, int a tinyint, etc.

Editar, junio de 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

Este artículo establece

Los criterios importantes son la cardinalidad y la relación página a fila.

Entonces, la elección del tipo de datos sí importa

No es solo el almacenamiento de la mesa lo que se tiene en cuenta. Si usa índices donde la columna int es parte de una clave compuesta, naturalmente querrá que las páginas de índice estén lo más llenas posible, esto es el resultado de que las entradas de índice sean lo más pequeñas posible.

Definitivamente esperaría encontrar que examinar entradas de índice en páginas BTREE sería un poco más rápido con tipos de datos más pequeños. Sin embargo, cualquier VARCHAR involucrado en las entradas de índice compensaría (anularía) las ganancias de rendimiento al usar TINYINT sobre INT.

No obstante, si las entradas de índice tienen entradas compuestas y todas son números enteros, cuanto más pequeños sean los bytes, mejor y más rápido.

Todas las cosas se vuelven más complejas cuando las bases de datos se hacen más grandes:

• las ventanas de mantenimiento deben ampliarse o reprogramarse
• copias de seguridad (la copia de seguridad completa al final del día se convierte en un absurdo consumo de tiempo, por lo que necesita un diferencial o incluso registrar copias de seguridad y hacer la copia completa una vez a la semana, tal vez una vez al mes)
• el mantenimiento del rendimiento se convierte en un factor de tiempo (la creación de un índice en una tabla de varias millones de filas no lleva un tiempo trivial de ejecución) y debe reprogramarse y empeora si la tabla es amplia ...
• Y transmitir esa copia de seguridad de 100 Gb a través de la red no es lo que yo llamo pan comido, especialmente si la red (por alguna razón desconocida) es obstinada al dejar la conexión en la marca de 75 Gb ... (sucedió con una instalación en la que estaba trabajando estaba haciendo una copia de seguridad en una unidad asignada en la red - red) ...

¿Y qué tipos de datos tienen que ver con eso? TODO. El uso de tamaños de fila más grandes de lo necesario hace que las páginas de la base de datos se llenen antes de lo necesario o incluso desperdicia espacio si el tamaño de la fila es tal que no se puede registrar más de un registro en la página. El resultado es que se necesitan más páginas para escribir y leer, se usa más memoria RAM para almacenar en caché eso (los registros más grandes necesitan una memoria más grande). Y dado que sus tipos de datos se especifican más grandes de lo necesario desde el disco, sus índices sufrirán el mismo problema, especialmente si agrupa esa clave primaria compuesta de 2 columnas BIGINT ya que cualquier otro índice creado copiará esa clave primaria implícitamente en su definición.

Si sabe que algunas columnas en una tabla que tendrán millones de filas o incluso una pequeña tabla que se FK' a varios millones de filas que no necesita un entero de 4 bytes para almacenar sus datos, pero un byte de 2 suficiente - use SMALLINT . Si los valores en el rango 0-255 son suficientes, TINYINT . ¿Una bandera Sí / No? Hay BIT .

Si bien para tinyintvs inthay diferencias claras, como el espacio en disco, las divisiones de página y el tiempo de mantenimiento, no habría ninguno de estos para varchar.

Entonces, ¿por qué no declarar todos los campos de texto como varchar(4000), ya que de todos modos solo usará el espacio necesario? Aún más, se le garantizará que sus datos nunca se truncarán.

La respuesta es, por supuesto:

1. Aclaración de sus intenciones (ya que nadie entenderá por qué un campo de nombre debe tener 4000 caracteres)
2. Validación, ya que desea asegurarse de que nadie ingrese una biografía completa como nombre.

Estas mismas razones también se aplican tinyint.