2010-05-15 15 views
7

Parece que veo mucha gente asignando arbitrariamente tamaños grandes a campos clave primarios/foráneos en sus esquemas MySQL, como INT (11) e incluso BIGINT (20) como usa WordPress.Tamaño de clave principal/externa de MySQL?

Ahora me corrija si estoy equivocado, pero incluso un INT (4) apoyarían (sin firmar) valores de hasta más de 4 mil millones. Cámbialo a INT (5) y permite valores de hasta un cuatrillón, que es más de lo que necesitaría, a menos que esté almacenando geodatos en NASA/Google, y estoy seguro de que la mayoría de nosotros no lo estamos.

¿Hay alguna razón la gente utiliza estos tamaños grandes para sus claves primarias? Me parece un desperdicio ...

+1

No, el campo de tamaño está en caracteres no bytes binarios. Así que int (4) solo puede contener hasta 9999 (en teoría, la base de datos puede almacenarlo internamente como más grande). INT (11) es en realidad solo un número de 32 bits. – MarkR

Respuesta

10

El tamaño no es ni bits ni bytes. Es solo el ancho de visualización, es decir, utilizado cuando el campo tiene ZEROFILL especificado.

y

INT [(M)] [UNSIGNED] [ZEROFILL] Un número entero de tamaño normal. La gama firmado es -2147483648 a 2147483647. El rango sin signo es 0 a 4294967295.

Ver this explanation.

0

no veo ninguna buena razón para utilizar un número mayor que entero de 32 bits para los datos de indexación en bases de datos normales negocio-clasificadas. La mayoría de ellos tiene tal vez millones de registros (o ese orden de magnitud).

+0

Tampoco lo hace MySQL. Usan enteros de 32 bits para el tipo de datos INT. El número en() no tiene relación con la cantidad de bits. –