respecto al tamaño ocupado, sí, pero mira esto que dice en el manual
Cita: MySQL soporta otra extensión para especificar de forma óptima el ancho a mostrar de un tipo entero en paréntesis después de la palabra clave para el tipo (por ejemplo, INT(4)). Esta especificación opcional del ancho de muestra se usa para alinear a la izquierda la muestra de los valores con ancho menor que el ancho especificado para la columna.
El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.
Cuando se usa en conjunción con el atributo de extensión opcional ZEROFILL, el relleno por defecto de espacios se replaza por ceros. Por ejmplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004. Tenga en cuenta que si almacena valores mayores que el ancho de muestra en una columna entera, puede tener problemas cuando MySQL genera tablas temporales para algunos joins complicados, ya que en estos casos MySQL cree que los datos encajan en el ancho original de la columna.
Tienes que usar el tipo de campo apropiado, es decir, el que cubre todas las necesidades de los valores que vas a usar, pero no más, y con el atributo de ancho de muestra apropiado para mostrar bien los datos y no tener problemas con los joins. Y piensa el sinsentido que es poner un ancho de muestra de 11 dígitos para un TINYINT que sólo puede tener 3 dígitos como máximo, o el peligro de poner un ancho de muestra 1 para un INT que cubrirá hasta 3 dígitos, por poner un ejemplo, cuando tengas que relacionarlo como PK o FK con otro campo numérico que tenga un ancho de muestra diferente.
Un TINYINT(1) sería por ejemplo óptimo para marcar sí o no con 0 / 1, un sólo digito de ancho de muestra, pero podrías escribir y guardar hasta 3 dígitos, si bien, en ese caso, podrías tener problemas en las salidas tabuladas y con algunos joins. Si tu rango numérico va a tener más dígitos, podrás usar SMALLINT, MEDIUMINT, INT o BIGINT, pero el uso óptimo dependerá del mayor ahorro de espacio sin comprometer el rango de valores de tus datos y teniendo en cuenta el ancho de muestra para mostrar los datos y relacionar esos números. Para el rango de números, te bastará con consultar los cuadros.
Un ejemplo de lo último, cuando relacionas PK con FK y ambos son INT, pero el ancho de muestra es distinto (por ej. uno INT(4) y otro INT(5), y también si son de distinto tipo, claro), no podrás establecer las relaciones con InnoDB entre esos campos. De modo que ten cuidado con añadir ese ancho al tuntún.
Un consejillo: usar el atributo UNSIGNED puede permitirte almacenar hasta un número mayor (el doble que si no lo añades), si tu rango no tiene negativos, y eso con un tipo de campo numérico que ocupa menos espacio.
Pero no seas demasiado "avaricioso" con el espacio no usado, y lo mantengas al límite, sin haber previsto bien si los números pueden ser mayores más adelante. La expresión "más vale que sobre que no que falte", aquí podría suscribirse con mas vale que sobre (algo) que no que falte. Piensa siempre en el peor de los escenarios, aquel en el que podrías necesitar más espacio para los posibles datos que tuvieras que almacenar en esos campos en el futuro